## Timeline
* Proposed: 2022-03-01
* Target Acceptance: 2022-10-01 (supporte…d in Nutmeg, **deprecated in Olive**)
* Earliest Possible Removal: 2023-05-01 (**removed in Poplar**)
### Considerations
This deprecation is conditional on the success of the [Tutor Adoption Initiative](https://openedx.atlassian.net/wiki/spaces/COMM/pages/3315335223/Tutor+Adoption+Initiative) in supporting the migration from Devstack to Tutor, which is described in more detail below. The Arch-BOM team at 2U-OCM (aka edX) is "willing to maintain Devstack as long as 2U developers still depend on it". So, although we are optimistic that Tutor will suit the needs of developers at 2U, it's possible this DEPR ticket might need to be delayed or rescinded in the future.
So, yes, this DEPR has a long timeline and conditions associated with it. Still, we're proposing this DEPR in order to communicate our desire and intention to move off of Devstack. That being said: 2U does not plan to drop support for Devstack in the immediate future. If you are using Devstack today, you're encouraged to try Tutor, but there is no pressing urgency that you switch.
For what it's worth: Even while this DEPR ticket is pending, and even if it's rejected, the community could still choose to officially recommend Tutor as an additional development environment for Open edX. @kdmccormick will be talking to the Build-Test-Release about the possibility of doing this for Nutmeg, which would give Nutmeg devs the choice of two different supported development tools.
## Replacement
The replacement for Devstack is Tutor. [Tutor](https://github.com/overhangio/tutor) is "the Docker-based Open edX distribution designed for peace of mind". It is both a deployment tool and a development environment. Tutor has been the only community-support production deployment method since Maple, although the Open edX docs and [website](https://openedx.org/community/develop/) do not officially recommend it as a development environment yet.
### Rationale
Devstack has several issues:
* It is not pluggable. This leads to two issues:
* It is large. Out of the box, it comes with a dozen IDAs and another dozen MFEs; new Open edX developers generally needs two IDAs (LMS and CMS) a few MFEs. In the past couple years, improvements have been made such that only a subset of IDAs are run by default. Still, cloning and provisioning are bound by the full weight of all services.
* Some IDAs like [enterprise-catalog](https://github.com/openedx/enterprise-catalog), in order to avoid being part of the large Devstack core, make a plugin-esque docker-compose.yml file that hooks into Devstack. This complicates the developer experience on those IDAs and also makes it harder to modify Devstack itself (because of the implicit plugin interface that such IDAs are using).
* Its images are slow to download. The Docker images used by devstack are built by running Ansible in a Dockerfile instead of using native Dockerfile commands. This means that the images are large and make poor use of the Docker layer cache, and thus take a long time for Devstack users to download.
* Many users find it difficult to diagnose and fix Devstack errors. Often, they find it more time/effort-efficient to destroy their volumes and provision from scratch instead of fixing the immediate issue.
* Provisioning takes a long time. This exacerbates the previous issue.
* There are several "upkeep" steps that must be independently done on a regular basis in order to keep Devstack working reliably. These include git-pulling devstack, git-pulling multiple app repos, pulling Docker images, and running migrations.
* Setting up a service in Devstack is completely tangential to setting it up for production deployment. Once it is set up, it takes attention and effort to keep the setup consistent between Devstack and production.
Tutor shows promise in many of these areas:
* It features a documented plugin API. Many IDAs (forums, discovery, credentials, et al) are implemented as plugins to Tutor. The core of Tutor includes just LMS and CMS, and [there is even work being discussed to factor those out into plugins](https://github.com/overhangio/2u-tutor-adoption/issues/10).
* Tutor's Dockerfiles are written using native Dockerfile syntax and are intentionally designed to be as small and cache-friendly as reasonably possible.
* Tutor has [actively-maintained documentation](https://docs.tutor.overhang.io) including a Troubleshooting section. Beyond that, Tutor has a dedicated forum community where maintainers and users help each other. Tutor also makes a point to have a consistent, documented, and debuggable CLI. For example, the `tutor dev` segment of the CLI is implemented entirely on top of `docker-compose` and transparently prints out the underlying `docker-compose` commands that it runs to aid in user debugging, using terminal colors to call out commands vs tutor logging vs actual output.
* Once Tutor is installed, provisioning involves one command (`tutor local quickstart`) and runs fairly quickly. Provisioning can be safely re-run without destroying existing data.
* Because Tutor uses the code in the Docker images by default, the user only needs to regularly git-pull the Tutor repo and the repos that they host-mount in, if any.
* Since Tutor is also the community-supported deployment method, one can support development and and production usage of an IDA all in a single plugin. Furthermore, using Tutor for both dev and prod allows operators to keep their dev and prod environments very similar with less effort.
For areas where Tutor could be improved, there is an [ongoing Tutor Adoption Initiative](https://openedx.atlassian.net/wiki/spaces/COMM/pages/3315335223/Tutor+Adoption+Initiative) which aims to support the transition from Devstack to Tutor through a mix of education, plugin development, and core Tutor improvements. Within the [initiative roadmap](https://github.com/orgs/openedx/projects/10), the "Dev Quality-of-Life" epic contains stories that should ideally close any existing gaps between Tutor and Devstack.
### Migration
Many developers can start using Tutor now, and many already are). Particularly, developers whose projects are encompassed by the LMS, CMS, MFEs, and [IDAs covered by existing official plugins](https://overhang.io/tutor/plugins) can generally transition their workflows over to Tutor. On the other hand, for teams that run IDAs with less community adoption (notably, teams at 2U), several new Tutor plugins will be needed in order for Tutor to fully replace Devstack.
There are no plans to help users migrate data from a Devstack instance to a Tutor instance. We recommend that folks start fresh when switching from Devstack to Tutor.
## Deprecation & Removal
### Deprecation steps
* Update [the development page on open.edx.org](https://openedx.org/community/develop/) to recommend Tutor instead of Devstack.
* `Ctrl+F` the docs for "Devstack", and where appropriate, update them to point at Tutor.
* Add a deprecation warning to [devstack's readme](github.com/openedx/devstack)
* Make devstack's `dev.up` Makefile target print a deprecation warning
* Update [the configuration docker role's readme](https://github.com/openedx/configuration/blob/master/docker/README.rst) with a deprecation message.
* In the description of https://dockerhub.com/u/edxops, warn that all images in the org are deprecated.
### Removal steps
* Archive https://github.com/openedx/devstack
* Delete the various `devstack.py` and `development.py` settings files unless otherwise depended upon.
* Delete the various `docker-compose.yml` files and Makefile targets that some IDAs (eg enterprise-catalog) use in order to integrate with Devstack.
* Delete the `docker/` role (incl. Dockerfiles) from github.com/openedx/configuration.
* 2U-specific stuff:
* Disable Jenkins jobs that build `edxops/*` Docker images and delete the code that defines said jobs.
* Decommission the `edxops` DockerHub organization?