In a recent tutor user’s group call there was a minor discussion on Devstack Vs Tutor, and @regis asked to see some of those points listed out.
Also as devstack’s repo got recently archived it’s apt to remember it and share my thoughts on it
Here’s my perspective a developer who used to primarily work on devstack and has now shifted to tutor. Please note that these are my personal views as a developer who’d do frequent changes to the code.
Advantages of Devstack :-
Familiarity :- Devstack was and is something that is familiar to work with because mostly that’s how we’d fire commands in prod environment too. Commands in dev env and prod env were same.
Ease of customisation :- As the containers had the volumes mounted to the repos from the get go, it was easy to cusomise the code in any repo and see the changes reflected directly. And it wasn’t ease of customising other repos, it was also ease of customising devstack repo itself too.
No need of a totally different documentation, apart from some commands, all the other stuff was same as OpenedX commands
More control with developer: Essentially same as above
Disadvantages of Devstack:-
Required more setup steps to make it work with other services (for eg: frontend apps, ecomm, credentials etc)
Configuration :- Configuring devstack to work as expected was a pain, too many URLs, too many ports, none of them come by default
Provisioning :- to wait while the provisioning was done was a pain
Prone to errors :- Installing devstack and making it work was easy for current releases, but for some of the older release if we do want to get back it was a bit difficult, there were various errors.
Advantages of tutor :
Easy to install, (just 1 command and Open edX is running ?? who would’ve thunk ?)
Pre-configured with defaults, I don’t have to do Oauth entries for different services anymore or configure the sites anymore, or worry about configuring SSO redirects etc.
Easy to deploy
Community support around tutor is just great, someone already has done the stuff that needs to be done or there is already a question around the issue being faced.
Good docs
Disadvantages of tutor
Build times:-
While it’s not true, but it feels like every little change might need a re-build
Lot’s of jumping around to be done for making a small change
Difficult to customise, in case of making a default work, it’s the best, but in case there are lots of custom changes involved it takes a while to get used to. While the methods are present and documented clearly to make the customisations, it’s a bit difficult to understand how to get going and just get your changes on your platform. As a person who is purely trained on Open edX and it’s code, it can be a bit difficult to not see your changes reflected easily, or to spend 30-40mins waiting for builds just to see a change which would’ve taken you a few mins and a restart in your old environments.
New commands and learning process, it takes a while to get adjusted to new environment of tutor and it’s commands. (Although this is going to be there for any new process).
High Memory requirement:- I am not sure if this is tutor related, it could be because of Open edX codebase itself or docker configurations etc. But I feel (it’s just a feeling, no solid metrics to back me up here) that while devstack used to work well with 8 GB RAM, tutor doesn’t work well at all with 8GB of RAM. In dev or Prod. Specially while building or while running in dev mode because of the watchers etc.
Many of these pain points are mostly a general reaction to anyone shifting to a new environment and it’ll get easier with time and usage of it.
Using tutor or devstack, community has come a long way from using Virtual box machines and vagrant.
One exciting thing: it feels like we’re getting closer and closer to having most of the UI implemented in MFEs. At some point, we’ll be able to remove all the static assets from edx-platform. As a test just now, I commented out the 14 commands in Tutor’s openedx Dockerfile that are related to static assets or Node.js, and the time it takes for tutor images build openedx dropped from 10 minutes to 30 seconds. And it runs fine, and works well with the MFEs - the main missing piece is that XBlocks cannot render in the learner MFE without the iframes/assets from the LMS. So it’s not quite usable yet. But, if we can solve that one thing (rendering XBlocks) and probably also implement the Instructor Dashboard in an MFE, then I think we can start to offer a “no legacy UI” build of Tutor Nightly that has all that stuff disabled and builds the platform much much faster.
Yes, the MFEs are slow to build, but at least if you’re only working on the platform, or only working on one MFE, you can rebuild just the thing you need much faster. (Also, MFEs aren’t inherently slow to build! We’re just locked into old tooling at the moment - it’s webpack, SCSS, and babel that are slow. With alternatives like SWC, Vite, Lightning CSS, etc. complete builds of even large MFEs can take under a second.)
Yeah, I understand but I don’t think that feeling is true. I’ve been using only the tutor nightly devstack for the past two years and I feel like I rebuild (via tutor dev launch -I) quite rarely, actually. Most of the time I can pull the latest build of edx-platform and it will run fine without a rebuild; or if I need to I can run migrations or rebuild static assets to fix a specific update requirement. It’s usually only if there are major changes to the system or python dependencies that I need to rebuild the images completely.
That is great, is it possible to get that updated file ?
Can you share how ? Yesterday for example I had to update a js file and for the life of me I wasn’t able to get it done with normal build images command. My changes were present in the container, but the assets were not updating, I had to build it with --no-cache to make it work.
But that’s not from scratch, right? Building from scratch, it takes my machine ~8 minutes to get from the ubuntu-20.04 base image to the point where system requirements are installed, Python retirements are installed, and edx-platform is cloned. At that point, it takes up to 10 more minute to build static assets, as you’ve pointed out. When your asset-free build took 30 seconds, I imagine that’s because all the other stuff was successfully loaded from the Docker
That’s why I’ve been working on with all the Paver removal stuff–I’m trying to get the static assets to “stick” in the Docker cache better, such that they’d only ever be rebuilt if you were actually modifying the asset sources. I’m hoping to get that into Redwood, with further improvements shortly after Redwood once Paver is actually out.
That said, removing static assets entirely would also work It’s bold to remove them now, with XBlocks and the instructor dashboard still using legacy assets, but maybe that tradeoff is worth it at this point?
Here’s an idea: Extract the edx-platform asset build into a tutor-legacy-assets plugin, which uses a Dockerfile patch to insert asset compilation into the openedx Dockerfile. It’d be installed and enabled by default so that XBlocks still render out-of-the-box, but developers could just run tutor plugins disable legacy-assets in order to get that 10 minute build speedup.
Nice, I like that idea. But it’s not just for the build speedup. It’s to create a forcing function to help finalize the transition to MFEs, and make sure they’re at feature parity or better.
It’s bold to remove them now, with XBlocks and the instructor dashboard still using legacy assets, but maybe that tradeoff is worth it at this point?