Repository navigation
[DEPR] Devstack #247
Description
Activity
Relates to openedx/wg-build-test-release#138
Since this is primarily a 2U project right now, we are planning on announcing this and gathering feedback.
2U is still planning on using this for the near to medium term until we're confident we can migrate successfully onto Tutor, but we can move it out of the openedx GitHub org to minimize confusion.
In general, sounds great!
Only thing is... MFE development currently sucks in Tutor >.< So nearly all frontend devs still use Devstack when they're trying to change MFEs.
Brian Smith is actively working on rectifying this, with promising results. Would you be willing to delay the deprecation further until Tutor has MFE dev sorted out?
Yup! I think we're still trying to understand the requirements needed here. I'll push out the acceptance date for another few months.
Discuss posting: https://discuss.openedx.org/t/deprecation-devstack/10703
@dianakhuang So, I know I had originally been a proponent of deprecating both configuration and devstack "into the edx org", under the understanding that if only 2U is using some parts of the project, then it's easier for both sides if we transfer those parts over to 2U. Since then, I've talked about this with my team at Axim, and come to understand that the situation is more nuanced than that.
The code in the openedx org is built from a mix of Axim-owned contributions and community-contributor-owned contributions (licensed to Axim under the CLA). We hold the code in this org for the good of all current & former Open edX contributors and users, and as the project's stewards we have a mandate to maintain ownership and ensure availability of all its repositories, even unsupported repositories.
Our procedure of archiving repos by transferring to the openedx-unsupported org lets us mark a repo as "unsupported" while still guaranteeing the repo's availability and keeping its ownership clear. So, if/when devstack and configuration are deprecated, we'll need to move them there.
@kdmccormick that sounds reasonable! 2U/edX.org should be able to then clone the repositories for our own use case after they are put into unsupported, then?
Obviously, this is our first stab and understanding how this process is going to work going forward.
Yes, you could fork from openedx-supported after that full deprecation & archival process.
Even in that case, though, I'd be curious what we could do to help keep 2U involved with community tooling.
Would you be forking devstack & configuration as a temporary stop-gap until you're able to transition off of them, or with the intent of using them indefinitely?
- If you're using them as a stop-gap, then I bet some other community members are also using them as a stop-gap. It could be worth keeping these repos un-archived until the replacement options (Tutor or otherwise) are viable to all or almost all community members.
- If you plan to use them indefinitely, then I bet some some other community members would see value in using them indefinitely, too, which I would see as an argument for keeping the repos un-archived.
Obviously, this is our first stab and understanding how this process is going to work going forward.
Same here :) learning as we go!
We are going to block acceptance because devstack is still used heavily by people who need to do development on MFEs outside of 2U.
@arbrandes @kdmccormick could you add more context on this?
43 remaining items
- added a commit that references this issue
on Dec 16, 2024 [inform]
- The cookie-cutter ultimately needs to be updated to match whatever final pattern you want around docker for new IDAs.
- Related, when creating the new codejail-service, we simply removed all the docker/devstack-related code. It may one day want to get updated with whatever pattern is created.
- Good point, I added a task to the issue description
- Thank you for doing that!
Update: While devstack itself is deprecated, there are still many tendrils to clean up in the openedx org , such as:
- outdated docs.
- devstack django settings files , whose removal is blocked by Simplify edx-platform settings openedx-platform#36215
- devstack-specific env.development files in the frontend-apps. Their removal is not imminent, but it also not blocked by any upstream concerns. I encourage any users of devstack forks to consider how they could either make those files tooling-agnostic (perhaps using local.openedx.io) or how they could operate devstack without those files being in the upstream repos.
@kdmccormick: I'm wondering if we could do away with the "blocked" status, and these tickets are helping me get more clear.
I think this ticket could move to Transition Unblocked and when updating to the new DEPR template, could get a task list for unblocking removal, and a task list for completing the removal. The first list would be required to get to Breaking Changes Unblocked. The Review After Date could simply be used as some future check-in date. Thoughts?
- moved this from Blocked to Transition Unblocked in DEPR: Deprecation & Removal
on May 16, 2025 Yes, I think that sounds reasonable! I updated the ticket status. I can add that info to the the tasklist in the future (I plan to update all my tickets in one go when I have a couple spare hours).
Reacted by Robert RaposaDocker compose files still kicking around: https://github.com/search?type=code&q=(org%3Aopenedx)+NOT+is%3Aarchived+path%3Adocker-compose.yml
- moved this from Transition Unblocked to Breaking Changes Unblocked in DEPR: Deprecation & Removal
on Jan 8, 2026 - moved this from Breaking Changes Unblocked to Transition Unblocked in DEPR: Deprecation & Removal
on Jan 8, 2026 - moved this from Transition Unblocked to Plan Accepted in DEPR: Deprecation & Removal
on Jan 8, 2026 This is waiting for new development environment settings files to be created. Blocked on the edx-platform settings refactoring.
We need a new base development settings file before this can be completed. The creation of this settings file is no longer blocked.
Timeline
Proposed: 2022-03-01
Updated Acceptance Date: 2024-03-12
Archived: 2024-03-19 (pre-Redwood)
Removal of devstack support from application repositories:
Original deadline: 2024-10-10Replacement
The replacement for Devstack is Tutor. 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 do not officially recommend it as a development environment yet.
Rationale
Devstack has several issues:
Tutor shows promise in many of these areas:
tutor devsegment of the CLI is implemented entirely on top ofdocker-composeand transparently prints out the underlyingdocker-composecommands that it runs to aid in user debugging, using terminal colors to call out commands vs tutor logging vs actual output.tutor local quickstart) and runs fairly quickly. Provisioning can be safely re-run without destroying existing data.For areas where Tutor could be improved, there is an ongoing 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, 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 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
Ctrl+Fthe docs for "Devstack", and where appropriate, update them to point at Tutor.dev.upMakefile target print a deprecation warningRemoval steps
devstack.pyanddevelopment.pysettings files unless otherwise depended upon.docker-compose.ymlfiles and Makefile targets that some IDAs (eg enterprise-catalog) use in order to integrate with Devstack.docker/role (incl. Dockerfiles) from github.com/openedx/configuration.PRs related to replacing devstack.py with a more general working development.py