Short answer is yes.
The Cookiecutter functionality grows as a function of whatever my clients request. Since our last meeting, in Lisbon, I’ve added more deployment logic for ecommerce, MFE, Discovery, and Credentials. I’ve also added some rudimentary tools for migrating native MySQL data to Tutor. Lastly, I reverted back to tutor’s default MongoDB service that runs “locally” on kubernetes as a pod, due to compatibility problems with AWS’ remote service. This however is also less than perfect, which you can read more here: https://discuss.openedx.org
What’s primarily of interest to me in Grove are the Azure and GCC (or Digital Ocean??) capabilities as the Cookiecutter is AWS-only, though my clients are keenly interested in leveraging other, lower-cost cloud providers.
I’d be willing to get involved in the heavy lifting of making Grove’s Azure/GCC code work inside the Cookiecutter assuming that this would lead to others becoming involved afterwards to keep this new code maintained.
As it stands, and as I’d mentioned at the last meeting, the basic care and feeding of the AWS-specific Terraform code is more than I’d prefer. Net, the Cookiecutter is a good tool for me, for upgrading clients and for doing clean installations, and overall it does save me considerable time and I get more consistent results by using Terraform. But the maintenance is non-trivial 