I wanted to share a general update to this audience. This afternoon i released v1.0.0 of the Cookiecutter, the first general production release for fully automated build & deploy onto AWS. I have a continued interest in porting this code base for Digital Ocean, GCC, Azure et al as well as other popular CI platforms.
Related: the original Github Actions build & deploy workflows have been refactored into a collection of reusable components that you’ll find here: https://github.com/openedx-actions. These components greatly simplify working with Open edX on Kubernetes and most are designed to work independently of the Cookiecutter itself. Today I also promoted several of these actions to v1.0.0. See the README’s on each regarding any details that might bear on your decision of whether of not to incorporate these into your projects. The following actions are now available for general production use:
@andres “any kind of aws resource” is a very broad statement, however, i can confirm that to date i’ve been able to find high-quality vendor-supported Terraform components for everything that i needed for the Cookiecutter automation of building the AWS environment, which includes: VPC, EC2, EKS, ECR, RDS, IAM, S3, Elasticache, Certificate Manager and Route53.
@Felipe will look into Helm charts - shared helm charts to deploy Open edX on Kubernetes looks like a good option to collaborate with. He will post his review of it within the next couple of weeks
If this confirms that it would be worth using to try to work together, @Felipe and @braden will work out a concrete proposal document together, for shared helm charts to deploy Open edX on Kubernetes, which will then be reviewed by the group.
We should definitely plan for a follow-up meeting – but maybe after we have completed the async steps decided during the meeting, and done at least one async pass of review on the document that will result from it? Synchronous meetings can be useful to resolve discussions that take a lot of back & forth – but for meetings to be useful there should be work & async discussions between them?
@Felipe@braden When do you think you will get a first draft up for review?
The inmediate next step was actually on me. Here is un update:
After our meeting I started my helm investigation enthusiastically and I think I have reached a point where its clear that writing helm charts for the openedx project is something that we at edunext would be very interested in.
Now, I suppose that we can write some plan together @braden. I’d use this place to leave some ideas that I think would be ideal to tackle or general concerns I have.
For the project
we need to make it flexible and modular
many composable libraries?
put everything behind flags?
get started with the project already adopting oep-55
And also, discussing with @Kelly_Buchanan this week we realized that there isn’t currently a good community working group to discuss this type of collaboration, and many other DevOps topics. The closest is the build-test-release working group, but it has its hands very full with managing the releases, and is understandably focused on it.
Maybe our current group could be a good starting point for a more general DevOps working group? From past experiences in other areas of Open edX, having regular meetings helps to find ways to collaborate more, and keep the momentum of initiatives going. It could also help liaising more with people from DevOps at 2U, which was what prompted this realization in the discussion with @Kelly_Buchanan – as 2U doesn’t use at all the named releases, the build-test-release discussions are often pretty far from their concerns.
There is already the Product Working Group happening at that time - could we do 1h earlier, ie 2022-11-22T15:00:00Z→2022-11-22T16:00:00Z? If that doesn’t work for some of us either, I’ll create a poll to find a time.