How cool! I’m an ex-Criteo as well (from rue Chapon and Place de l’Opéra)
I had a big conundrum when I first started work on the k8s integration: should I use Helm or not? In the end, I decided not to go with Helm for the following reasons (in decreasing order of importance):
- At the time,
kubectl seemed sufficiently mature to do most of the work performed by Helm.
- Helm does a lot of templating that conflicts with tutor’s own templating system. We would have been forced to have both systems coexist, and that would have been quite impractical.
- Plain kubernetes manifests have a bigger mindshare/user base than Helm charts, simply because they do not require helm to be installed.
- I wanted to have a simple solution that could be extended by other users, if necessary. Simple Kubernetes manifest files filled this requirement.
- Writing Helm templates is an even bigger pain in the ass than writing Kubernetes manifests.
Finally, (and I’m not quite sure about this one) it seems like it’s not so easy to extend Helm charts using a plugin approach similar to the tutor plugin system.
That being said, I would be more than happy if someone (you?) developed a Helm chart for Open edX. Everybody wins when we improve the tooling around Open edX.
My understanding (but I admit I may very well be wrong) is that Helm charts are great for installing apps that do not have much modularity. With Open edX, there are so many moving pieces that’s it’s difficult to write a Helm chart that will work for everyone.
Can I ask what’s your use case for running Open edX? Feel free to PM me if you’d rather not discuss this publicly (in English or French).
I read a post on the OpenEDX forums that suggests they are going to start looking at k8s themselves
I am curious to see where this is going to go. That would mean that edX would start running containerized applications, and this would be quite a revolution. It’s no small feat to migrate the entire infrastructure of a 200-engineer team.