Tutor Analysis

Owned by Feanil Patel
Last updated: Feb 09, 2022 by Kyle McCormick
4 min read

This learnings from this analysis and others are being acted upon in a Tutor Adoption Initiative, which aims to make Tutor viable to fully replace for Devstack. Keep an eye on that project for the latest on Tutor enhancements & extensions.

Table of Contents

1 Overview

An evaluation was made in March 2021 of the readiness of Tutor as a potential replacement of the Open edX devstack.

At this time, Tutor has enough gaps that it is not yet ready. However, next steps were also documented.

2 Rubric

Capability

Tutor

Open edX Devstack

Capability

Tutor

Open edX Devstack

Make edx-platform code change and see it via runserver

Works

Works

Run Specific Unit Tests

Works

Works

Run Quality tests

Works

Works

Make discovery change and see it via runserver

Doesn't work missing ES7 related changes.

Works

Run discovery unit tests

N/A

Works

Make an MFE code change and see it in the browser

No MFE Plugins right now.

Some MFEs are supported but not all

Run MFE tests

N/A

Works

Make a backend config change

Works but has a tutor specific layer to it

Works but is complicated by ansible

Run MFE outside devstack/tutor

Works once all the relevant host names are updated

Works

3 Steps for Local Dev

Tests were done with the version of Tutor in this pr: https://github.com/overhangio/tutor/pull/407

NOTE: Many steps will update the docker-compose.override.yml file. Here is what the final version looks like:

version: "3.7" services: lms: volumes: - /home/feanil/src/edx-platform/:/openedx/edx-platform - /home/feanil/.local/share/tutor/volumes/edx-platform-venv/:/openedx/venv cms: volumes: - /home/feanil/src/edx-platform/:/openedx/edx-platform - /home/feanil/.local/share/tutor/volumes/edx-platform-venv/:/openedx/venv lms-worker: volumes: - /home/feanil/src/edx-platform/:/openedx/edx-platform - /home/feanil/.local/share/tutor/volumes/edx-platform-venv/:/openedx/venv cms-worker: volumes: - /home/feanil/src/edx-platform/:/openedx/edx-platform - /home/feanil/.local/share/tutor/volumes/edx-platform-venv/:/openedx/venv discovery: volumes: - /home/feanil/src/course-discovery/:/openedx/discovery - /home/feanil/.local/share/tutor/volumes/discovery-venv/:/openedx/venv

3.1 Steps for Setting up a branch version of Tutor

git clone git@github.com:feanil/tutor.git cd tutor git checkout feanil/more_resilient_warning_suppression mkvirtualenv -p python3 tutor pip install -e .

3.2 Setup to do edx-platform Dev

  1. Setup for development per first section of https://docs.tutor.overhang.io/dev.html, summarized with the commands below:

    tutor local quickstart tutor local stop tutor images build openedx-dev

  2. Override source code mounts to point to local edx-platform code by following instructions in this section: https://docs.tutor.overhang.io/dev.html#override-docker-compose-volumes

    • Note: See first line in each volumes section in example .yml file above.

  3. Copy container’s venv to the host using the bindmount command.

  4. Update docker-compose overrides file to mount the local venv into the container.

    Add a line like the following to the override file for each of the containers (lms, cms, lms-worker, cms-worker)

  5. tutor dev run lms pip install -r requirements/edx/development.txt

  6. tutor dev run lms ./manage.py lms migrate

  7. tutor dev runserver lms

3.3 Adding Discovery

The following instructions are not enough to get discovery working because we need to be using the ES7 images and update the settings file to inject the correct overrides into tutor to work with elasticsearch DSL. We did not proceed with that work at this point.

  1. pip install tutor-discovery

  2. tutor plugins enable discovery

  3. Copy discovery container’s venv to the host using the bindmount command.

  4. Update docker-compose.override.yml to add discovery service with local venv and discovery code.

3.4 Running with an MFE next to tutor

  1. Download MFE

  2. Update .env.development

    • Replace all occurances of localhost:18000 -> local.overhang.io:8000

    • Replace localhost:1997 -> local.overhang.io:1997

  3. Run webpack server manually to set host to local.overhang.io.

  4. Navigate to local.overhang.io:1997

4 Questions for Régis

  • After I update tutor/templates/apps/openedx/settings/partials/pre_common_all.py how do I update my local tutor settings files?

  • Why does the run command set permissions every time?

    • Should we be running exec instead?

  • Why do we have to re-build the image between dev and test? https://docs.tutor.overhang.io/dev.html#running-edx-platform-unit-tests

    • Could there be a simpler workflow?

  • Is setting up to test e2e something you're planning to do?

  • If we want to change Django settings, is this where we should be using some existing hooks that we're not aware of?

  • Why have your own Django settings files? Is this due to historic reasons?

5 Next Steps

  • Talk to Régis about our open questions. Include Adolfo in conversation.

  • Reevaluate in the future after some of the gaps have narrowed, or prioritize helping narrow the gaps. See the following notes on the current stance on various questions:

    • Should we replace devstack with tutor today? No.

    • Should we replace devstack with tutor someday? Maybe.

    • What's preventing us from doing it now?

      • Missing MFEs

        • Currently Tutor has no MFE plugins. We would need to build this.

      • Missing Backend Plugins

        • Credentials

        • Registrar

      • Out of date with Master for data layer services (mongo, es)

        • Example: Course discovery elasticsearch

        • This may be tricky to fix and would involve updating tutor's settings files and default images.

          • Replacing default images is already supported.

          • We may be able to use hooks to update settings which is the other thing that would be needed.

      • Not all Unit Test work for the LMS

      • Other various use cases that devstack currently supports and Tutor doesn't (not making a value judgement, just calling out for completeness.)

        • e2e testing

        • Generating Programs Data

        • No quick script to provision all plugins at once, each service/plugin is manage individually.

          • Missing a "do all the things" script is fine if we want the users to know and do each thing they want manually.

          • But missing the "do all the things" scirpt does increase the number of things a developer needs to know and do manually.

        • The option to run with NFS mounts

 

Former user (Deleted)
March 9, 2021

I think @Feanil Patel means that the plugins need to be pip installed, and thus, the user needs to know what plugins they want/need in advance.

Personally, I think this is a good thing, as it clearly separates what’s core to the platform and what’s an addon - particularly since addons may not be as well supported as core. Also makes the default environment much lighter.

Kyle McCormick
January 31, 2022

2U (or anyone else) could make a plugin metapackage, right? As in, if all 2U developers needed five plugins, they could release a tutor-contrib-2u-dev package that did nothing but transitively install those five plugins by listing under install_requires.

They plugins would still need to be individually enabled, a la

but if we changed tutor enable to allow multiple arguments, that could be futher shortened to

Doesn’t seem bad to me. @Feanil Patel , what do you think?

Feanil Patel
January 31, 2022

Kyle, that’s a good point, a meta-package would solve this issue but building and maintaining a meta-package would be new work that 2u would need to take on. So we called out this manual step which is not too bad but would need to be addressed in some way if we didn’t want to introduce lots of manual steps as a part of the devstack bootstrapping process.

 

As it stands, I think 2U would have to build and maintain their own dev on-boarding docs around devstack instead of being able to rely on the upstream tutorials. This is fine but work worth calling out.

Kyle McCormick
January 31, 2022

but building and maintaining a meta-package would be new work that 2u would need to take on.

Yes. Should be pretty easy in comparison to the other Tutor plugins they will need to build.

So we called out this manual step which is not too bad but would need to be addressed in some way if we didn’t want to introduce lots of manual steps as a part of the devstack bootstrapping process.

+1, this alone isn’t bad, but we’ll need to keep an eye on not dying from 1000 cuts.

As it stands, I think 2U would have to build and maintain their own dev on-boarding docs around devstack instead of being able to rely on the upstream tutorials

I am really hoping that their docs would only need to be a thin layer on top of Tutor’s docs (ie “go follow Tutor setup, but at step 3 install our plugin”) and the docs of the services they maintain instead of a full-on private duplication of them. It would be better for everyone if 2U was consuming and providing feedback/fixes on Tutor’s official docs.