Repository navigation
[DEPR]: Phase out edx-configuration #51
Description
Proposal Date
30 November 2020
Ticket Acceptance Date
October 13, 2023
Technology Removal Date
After Redwood Cut
First Open edX Named Release Without This Functionality
Sumac
Rationale
N/A
Removal
N/A
Replacement
Deprecation
No response
Migration
No response
Additional Info
For now a placeholder, this will eventually describe in detail how edx-configuration will stop being supported by edX, including:
- A date and/or Open edX release from which
edx-configurationwill no longer be supported - A suggested alternative (possibly Tutor, via BTR-43)
- A suggested migration plan
Notes from Comments:
Kyle McCormick
February 11, 2022, 9:08 AM
Edited
I want to draw a distinction here:
In the broader Open edX community, openedx/configuration is already rapidly being phased out.
As of Maple, the Ansible Native installation support was officially dropped in favor of Tutor. Some community members still use Ansible Native but I believe most intend to migrate to Tutor.
Devstack images are built from openedx/configuration, but we are replacing Devstack with Tutor, and will be probably ready to drop official Devstack support as of Nutmeg or Oak. (I need to make a DEPR ticket for this :)
As far as I know, the other miscellaneous playbooks in openedx/configuration are not generally used by the community, although we should check that assumption (eg, does OpenCraft depend on them for OCIM?)
In my experience at edX/2U, though, they still use openedx/configuration heavily, especially in its older services.
They use it for:
- build AMIs
- deploying to prod/stage/sandbox
- various automation needs
- building devstack images
Their newer services use less/none of openedx/configuration.
There has been a push away from openedx/configuration, but migrating legacy services off of it will require non-trivial effort
Based on that:
I see openedx/configuration as already de facto deprecated in the Open edX community. We should clean up this ticket and use it to formally propose the deprecation and see if anyone has objections to the direction we’re already rapidly heading.
If that ^ DEPR goes though, edX/2U may still depend on the code for a while. So, the “Removal” step of this ticket could be transferring/forking the repostory back to the edx GitHub organization so that they can use it as long as they need to.
- The work of removing edX/2U’s dependency on edx/configuration repo is probably best represented in their own tracking system instead of in a community DEPR ticket.
Jeremy Bowman
February 11, 2022, 8:33 AM
https://openedx.atlassian.net/wiki/spaces/AC/pages/2107441855/Braindump+on+Configuration+Today+and+Future is apparently the most detailed write-up we have so far regarding this. As noted in the original description, this ticket was less of “we plan to immediately prepare for this” and more “this is coming down the pipeline, if you have any objections or suggestions we’d like to hear them”. Progress on it so far has been gated on spare SRE bandwidth.
Original Jira Issue: https://openedx.atlassian.net/browse/DEPR-122
Activity
dianakhuang commentedon Jun 21, 2022
Big usages of configuration:
Maybe we can start shaving some of these off the list.
jmbowman commentedon Jun 21, 2022
I've created openedx-unsupported/devstack#943 as one step towards this and assigned it to the Arbi-BOM squad.
dianakhuang commentedon Aug 16, 2022
At the very least, we have managed to find a solution for codejail on Tutor, which was one of the blockers of this work.
robrap commentedon Dec 1, 2022
How will New Relic configuration be handled in the future, like this file: https://github.com/openedx/configuration/blob/master/playbooks/roles/edxapp/templates/newrelic.ini.j2?
I ask because I want to add some settings around logging/tracing, and at this point I'm just planning on changing them here and having it used everywhere. I'm hoping 2U is the only org affected, because no one has complained about any other changes.
jmbowman commentedon Jan 11, 2023
@robrap There are already several services that don't use the configuration repo, but instead have their production Docker images generated by in-repo Dockerfiles. So if there are any New Relic settings that need to be set via config file that we want active across services, we'll have to make sure the config gets into those images (and probably adjust the cookiecutter to make sure new services' Dockerfiles get that by default).
robrap commentedon Jan 11, 2023
Thanks @jmbowman. That's good to know. So far, I think we just have one server-side config related to browser. I imagine that only affects server-side templates, but I'm not certain.
dianakhuang commentedon Jul 13, 2023
Since this is mostly used by 2U, we are planning on announcing and moving this into accepted and transitioning the repository back into the
edxGitHub organization.kdmccormick commentedon Jul 13, 2023
Sounds good to me!
Agrendalath commentedon Jul 13, 2023
@dianakhuang, will this repository become private after this date? We are still using it for our deployments.
We also use it for building devstack images because:
dianakhuang commentedon Jul 13, 2023
@Agrendalath no, we are not planning on moving it private. We are merely trying to indicate that it's the 'old, not-recommended' way of doing things by taking it out of the openedx org and indicating that it is primarily designed to support edx.org. There might be more 2U-specific customization in that case, but it might be worth it to figure out what can and should be split into other scripts/resources that might be more generalizable.
robrap commentedon Jul 14, 2023
@dianakhuang: This DEPR was moved to communicated without actually including all of the TBD data.
If others are still using edx-configuration, we might not want to move edx-configuration unless we plan to drop it from the next named release? We could also document that it will be available in the edx org, but once we move it, it has a higher chance of picking up 2U specific changes (as parts of it move or are replaced), and it will likely be archived once we are done with it.
13 remaining items
kdmccormick commentedon Feb 26, 2024
@dianakhuang Gotcha, sorry for the mixed messages, let me talk to my team and make sure we're on the same page :)
kdmccormick commentedon Feb 26, 2024
@dianakhuang Thanks for bearing with us. The process we'd like to follow, both for this and devstack, are:
For $ACCEPTANCE_DATE, 2 weeks from now is fine since we've been tossing this around for so long, but you could push it out further to the future if you aren't ready to fork it yet.
feanil commentedon Mar 21, 2024
We did this here: https://discuss.openedx.org/t/deprecation-edx-configuration/10702 and there was no resonse so we will proceed with archiving this repository.
The current plan for this is to archive this after redwood is cut to give users one last release with configuration.
docs: Add a deprecation warning.
feanil commentedon Mar 21, 2024
I've created openedx-unsupported/configuration#7137 to further communicate the deprecation before the removal.
feanil commentedon Apr 4, 2024
This is blocked until after the Redwood Release. Once Redwood is released, this can be archived.
feanil commentedon May 6, 2024
We ended up doing this early, if we need it tagged for Redwood, we can go back and add redwood branches and tags.