Devstack Vs Tutor

Hello All,

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:- :frowning:
  • 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.

Please feel free to give your inputs on these.


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.

Yes, here: Comparing · overhangio/tutor · GitHub

Rebuild static assets: tutor dev exec lms openedx-assets build --env=dev

Run migrations: tutor dev exec lms ./ lms migrate

(assuming LMS is running already; if not, change exec to run)