Tutor Adoption 4: Devstack Parity: Dev Workflows Option 2: Quickdev++

[kdmccormick]

Background

#144 describes three options for improving tutor dev workflows around locally-changed code and requirements. This is one option.

Tasks

Using the quickdev plugin prototype and its TEP discussions as a basis...

• Propose a design for a new plugin that uses named volumes to improve Tutor development workflows. Things to discuss:
  • Will it be official or unofficial?
  • Who will maintain it?
  • What should we call it? (one suggestion: devtools)?
  • Keeping in mind that each new named volume adds state and risks staleness: How should named volume management work? More specifically, what commands should be available and how should users be messaged when their volumes are created, destroyed, getting old, etc.?
  • How will other Tutor plugins make their services work with this plugin? Will we need to add new filters?
    • Example: COMPOSE_DEV_IMAGE_NAMED_VOLUMES filter could be introduced, as a map from images to their named volumes. That would allow volume management commands to be generalized beyond edx-platform.
  • What changes need to be made for MFE development? The quickdev plugin was written with just edx-platform in mind, so it's only been tested on local changes to Python services (lms & cms) and Python packages (xblocks, mainly).
• Write up DevExp issue(s) to implement the plugin.

Notes

The tasks are based on discussions from the quickdev TEP, in particular these points from Mehdi Bouhali:

TL;DR:

quickdev is a life changer that needs to look less @kmccormick’ly opinionated and more community-like, through a thorough discussion about features and implementation.

Stateful containers?

Developers should be aware of mounted volumes by providing the proper feedback messages (info/warning) in the best places (saving configs, starting/restarting containers, etc.)

A band-aid on a wooden leg is indeed meaningless

I agree that issues ought to be solved upstream instead of providing fixes that would contribute to further delaying radical, in-depth solutions.

You can’t cast your wooden leg, but even a healthy person would love the comfort of a motorized wheelchair

I don’t think the tutor dev community should be deprived of quality-of-life improvements for this reason. The Tutor project has an advantage over Open edX in the way it has less strict barriers to embracing positive change. And whenever our wooden leg gets upgraded to become a modern prosthetic, we’ll just make sure to do the proper feature deprecations.

dev/local/k8s disparity ?

if we are relentless in integrating quickdev features in the Tutor core, why not instead work towards adopting quickdev into the official tutor plugin family with a proper adoptive name (e.g. tutor-devtools)?
We can then elaborate on which features to include, and how they would fit in the full picture (i.e. interoperability with the existing plugins). Then, in the end, add to the Tutor core any actions/hooks/defaults required by the plugin to serve its purpose (which is to streamline the Open edX development processes).

[kdmccormick]

Closed in favor of #146