Ok, so this is definitely not intended to flame but though “not supported”, if my goal is to do local dev with k3d/k3s and then prod with a “proper” kube, is there major reason why I need to drive my installs with tutor and not just helm? I guess there is probably some init logic there but could that not be done in an init container?
I have been searching around and came across the harmony stuff but that seems to predominantly be just so tutor can do multi-client installs with shared resources, rather than let us do installs with helm. From a quick reading of the docs, it seems tutor just drives kustomize when installing to kube… And copilot has done what looks like a half decent conversion to a helm chart… So is there still lots of critical stuff tutor is doing on top of that?
I realise I could go and read all the tutor code but is there a resource somewhere that has a “middle level” of information about why tutor is necessary and a list of the features (with technical details) it provides between “it’s complicated” and “read the code”?
I have my own helm chart that installs Supabase running on CNPG, and I even replaced Kong with Istio (+ a hack or two) and Gateway rather than Ingress. My eventual hope/goal is that a lovely maintainer will merge the Postgres compat PR that now looks ready-ish and then try and hack together a chart that allows me to use that Supabase/PG. Maybe even give FerretDB or DocumentDB a try to replace Mongo and be PG all the way down…
Does all this just sound like an insane waste of time?
is there major reason why I need to drive my installs with tutor and not just helm?
Depends on what you want to achieve. If you don’t care about retaining compatibility with the Tutor plugin ecosystem and don’t mind maintaining you own chart then there shouldn’t be too many technical aspects stoping you. The main issue would be the Docker images, as they are somewhat tailored for a Tutor deployment and are pretty much only built using Tutor.
A lot of Open edX providers cannot make this concession because their customers may require them to deploy a service developed by a third party using Tutor. If your are the owner of your Open edX installation and won’t need to add arbitrary services developed by other members of the community you can take full ownership of your deployment setup by developing your own chart.
I realise I could go and read all the tutor code but is there a resource somewhere that has a “middle level” of information about why tutor is necessary and a list of the features (with technical details) it provides between “it’s complicated” and “read the code”?
I don’t think there is. You will have to read the code. The Tutor K8S setup is a kuztomize application so you have to translate all the manifests files into helm templates. You will also have to keep in mind the configuration files for the core stack (tutor/tutor/templates/apps at c031d2473a65b5413784bbcc7dcbcc50865a57e4 · overhangio/tutor · GitHub) the platform defaults aren’t particularly the best and certainly not plug and play. You will also have to implement the jobs (tutor/tutor/templates/jobs/init at c031d2473a65b5413784bbcc7dcbcc50865a57e4 · overhangio/tutor · GitHub) via either init containers or helm hooks.
And don’t forget that tutor-mfe is pretty much an obligatory plugin.
This is a lot of work and you are not going to find much help online because no one in the community is working on something similar, but I don’t think is impossible.
1 Like
Thanks very much for such a detailed reply. Copilot has also got me quite far along already. I have a few days more to dedicate to exploring really whether openedx is the right platform for the project, so I’ll plod along I think. I would probably even claim python as my “best” language, so I have no excuse!
I must confess, from what I’ve seen so far, I think you could radically simplify and increase security and stability by throwing compose away and rebuilding for k3d/k3s + helm (with either docker or podman underneath). It would allow a single code path with much less bespoke mechanics (so easier for community and newcomers to contribute). The work that seems to be going on to make the config sane will also obviously make this easier. Plugins could be implemented with charts (at least in lots of cases, needs more exploring…) and I definitely haven’t seen anything yet that isn’t easily achievable with k3d (on linux/wsl2 anyway, no idea about mac) - local certs, building local and pushing to the integrated registry, etc. It would also make moving to use secrets for, well, the stuff that should be secrets a lot easier… (and in git for the rest). You already provide k8s support and everything is intended to be run through `tutor`, so with the exception of rewriting some plugins (which may have to get rewritten anyway with the config reworking?), actual end users wouldn’t see a difference…
But these are words. I have a similar setup that does Supabase, which is probably at least half as complicated to get running as openedx, so it’s not all hot air!
Once I have a github repo that achieves some of this (the k3d part, not rewriting tutor 
), I’ll post back. I’ll probably play around with using valkey (via an operator) instead of redis, ferretdb instead of mongo and postgres instead of mysql (both using CNPG). The postgres part will give me a chance to validate building and deploying edx-platform locally.