Status Quo

There are currently a few different choices of Open edX development environment, each with its own pros and cons:

• Tutor is the option recommended by Axim for most Open edX developers, but doesn’t yet satisfy the unique needs of most developers at 2U (developing on master in a wide range of services).

• Devstack, the previously recommended Open edX development environment, is still widely used at 2U and other companies despite fairly strict hardware requirements and an assortment of yet-unresolved pain points.

• Hosted Devstack is a deployment of devstack on an EC2 instance, used by a growing subset of 2U developers to work around hardware limitations and difficulty in maintaining a local development environment. It is currently only usable by 2U employees and contractors, and inherits several of devstack’s limitations.

Pain Points

Common to all current environment options:

• Data provisioning - Loading of data almost always needed for common development tasks is slow and prone to frequent breakage, and the data set is inadequate for many tasks.

• Configuration - Each service is configured through a combination of Django settings files, YAML files, and environment variables. The whole is hard to understand, and breakage due to misconfiguration is common.

• Legacy static assets - Some of the older services (especially edx-platform and credentials) include large amounts of legacy UI code whose configuration is entangled with that of the backend code. The build process for these UI assets is slow, complex, prone to breakage, and must be repeated often for installations and configuration changes.

Local Devstack & Tutor:

• No Windows support - Attempts have been made in the past to get a local devstack installation working on Windows, but none have fully succeeded. Hosted devstack and remote Tutor installations are currently the only viable options on this platform.

• Docker Dekstop licensing (macOS) - The currently recommended Docker installation for macOS, Docker Desktop, is proprietary software which requires license fees under certain conditions which are frankly hard to understand for most developers. New developers are routinely tripped up trying to figure out if it’s actually OK for them to install it or not.

Devstack:

• No ARM CPU support - The current Docker images for devstack are x86-only; they can be used on developer machines (like recent Macs) with ARM CPUs, but the performance is fairly poor.

Hosted Devstack:

• Cost - Maintaining a hosted devstack installation costs money, and more than it should because we haven’t been able to fine tune the instance sizes, idling behavior, etc. as effectively as other publicly available cloud environment management tools can do.

• Only 2U staff - As it was designed to run in 2U’s cloud computing infrastructure, only 2U employees and contractors are currently allowed to create hosted devstack environments.

• Complex setup - Figuring out how to first create a hosted devstack environment is difficult, even when following detailed instructions.

Tutor:

• Limited set of services - Tutor includes the services most commonly needed for small installations of Open edX and the option to add a few more, but there are several services actively used by 2U and other large installations which aren’t yet supported at all.

Improvement Projects

Work is in progress to address many of the pain points above, here are some of the most notable ones:

• Ansible-free Devstack images (complete, Arbi-BOM) - The use of Ansible made the devstack images very complex and significantly larger than necessary, and ultimately served as a blocker to ARM CPU support. This was a significant driver in Tutor’s creation and adoption, but the images are now finally generated from simpler Dockerfiles in each service’s repository.

• ARM Devstack images (in progress, Arbi-BOM) - With Ansible usage now eliminated, this is a much simpler task and may be complete sometime in early June 2023.

• Resolution of Devstack’s most pressing bugs & warts (in progress, Arch-BOM) - Arch-BOM is reaching out to people who are known or suspected to have had trouble installing or using devstack recently, identifying and resolving the issues most responsible for preventing people from getting their work done quickly.

• edx-platform static asset build simplification (in progress, Axim) - Steady progress is being made on trimming down the number of layers of complexity in this process which is needed for most development environment installations (and many code changes in our largest service).

• Better caching in Tutor builds (in progress, Edly & Axim) - Significant progress has been made on using different forms of caching and Docker image build optimization in Tutor to reduce the duration of data provisioning, static asset (re)generation, etc. Further such improvements are in progress.

• Legacy UI conversion to MFEs (in progress, several teams) - Intensifying pain in maintaining our legacy UI code has prompted an acceleration in effort to completely replace that code with micro-frontends implemented in a much newer (and easier to maintain) technology stack. It’s a big project, but solid incremental progress is being made.

• Hosted devstack cost optimization (in progress, SRE) - 2U SRE is in the process of optimizing the hosted devstack EC2 instance types, etc. to reduce the usage cost as much as practical without significantly impairing their usability.

• Hosted devstack Slack launcher (starting soon, Enterprise and SRE) - Streamline the process of launching a new hosted devstack environment via a Slack bot.

• OEP-37: Dev Data (designed, implementation starting soon, Arch-BOM) - This project is intended to dramatically improve the volume, reliability, and performance of our development/test data, and make it largely independent of the chosen development environment.

• Docker Desktop substitute (planned, Arch-BOM) - There are a few viable substitutes for Docker Desktop with better licensing and/or performance. We are likely to update our guidance on recommended Docker installation for macOS by the end of 2023.

• OEP-45: Configuring and Operating Open edX (designed, implementation pending) - This is a good first stab at cleaning up

•