If you develop or deploy Open edX, you may need to update some URLs to several repositories due to redirects that have been lost.
What happened
Several years ago, when 2U and Axim split, the Open edX git repositories were moved from the edx GitHub org to the openedx GitHub org. This left redirects in place; references to the repositories under the edx org continued to work.
Today (2/26), 2U moved to consolidate some GitHub orgs, moving archived repos from the edx-unsupported org into edx. What we did not anticipate is that among those were some old edx.org-specific forks of six Open edX repos (listed below). These had the same names as their origin repos.
The result was that instead of being redirected to the correct repos in the openedx org, requests for the repos in the edx org received these 3 year old forks. This broke deployments at 2U and caused git errors for developers.
The redirects cannot be restored readily. 2U is replacing these unexpected repos on the edx side with “stub” copies that have a README pointing to this post and are otherwise empty. The remaining work is to update references in code, configuration, and documentation. At a high priority this includes deployment and dependency configuration; at a low priority this also includes PR and issue links in documentation. (These are all changes that needed to be made eventually, but due to today’s name collisions, the need to change them has become urgent.)
Affected repos:
If you have any of the following checked out, you will need to update them according to the instructions below:
edx-platform
cs_comments_service
XBlock
xblock-sdk
devstack
django-require
Action items
Developers
Go to your local copy of each repo and run git remote -v. Find the remote that lists a URL pointing to either the openedx or edx version. (For most people this will be a remote called “origin” or “upstream”, and may be the only one.)
If the URL uses the openedx org, you’re all set. You don’t need to do anything.
If the URL instead uses the edx org, you’ll need to update that remote, e.g. git remote set-url origin ...
Maintainers and deployers
We’ll need to ensure that any remaining pointers to the edx URL for these repos are updated to the openedx URL, in both Open edX repositories and in private deployments.
Here’s a GitHub search query that will find git and http URLs that probably need to be updated:
org:openedx NOT is:archived /(?i)github\.com[^A-Za-z]+edx\/(edx-platform|cs_comments_service|XBlock|xblock-sdk|devstack|django-require)\b/
You can also add NOT language:reStructuredText NOT language:Markdown to exclude instances in documentation, since those are lower priority to update.
(The Arch-BOM team at 2U has updated all of the critical locations that we could find in public repos, but private repos, documentation, and non-git-controlled text have not been updated.)
2U-side remediation
For any repo that was moved from edx to openedx and that was replaced on the edx side by accident this week, the process is:
Move the edx-org repo to a new name, preserving its PRs, issues, and other history.
Create a new repository in its place, breaking the redirect that is unavoidably created in step 1.
In the new repository, create a README instructing people to update the URL that brought them there and pointing to this page.
I think that’s the most we can do on our side to smooth the transition. My apologies to anyone who is experiencing disruption from this.
Thanks for the detailed write-up Tim! This issue will also affect all users running Tutor<13.1.3 (Maple release). These users stuck on older releases should add a build argument to their build commands:
tutor images build -a EDX_PLATFORM_REPOSITORY=https://github.com/openedx/edx-platform.git openedx
One option for a temporary fix on older releases could be to make a patch in openedx-dockerfile-git-patches-default with a git config change, something like
Thanks for letting me know about this @bryan.w!. I ran into this issue trying to build a new Docker openedx image with Tutor for the nutmeg release because of this dependency on a repo that’s now not there due to this article’s update mentioned above.
# original repo is not maintained any more.
git+https://github.com/edx/django-require.git@0c54adb167142383b26ea6b3edecc3211822a776#egg=django-require==1.0.12
@bryan.w Figured it out. The openedx-dockerfile-minimal patch comes before git is actually installed. I moved this django-require command to patch openedx-dockerfile-git-patches-default like you mentioned above and the tutor image build openedx works great.
Location of openedx-dockerfile-minimal in relation to git install
@bryan.w I was afraid that even with that .insteadOf git command above that it would not know how to grab version 1.0.12 for openedx-django-require because it doesn’t exist.
Here is what I’m seeing in the virtual environment within the LMS container.
I think that I’m going to need to install latest version of openedx/django-require to ensure that it can be used by the edx-platform apps.
Moving this to the openedx-dockerfile-post-python-requirements patch as well because it comes after the ./requirements/edx/base.txt call.
hooks.Filters.ENV_PATCHES.add_items([
(
"openedx-dockerfile-git-patches-default",
"""
# Fixing this `django-require` package to be from `openedx` org rather than `edx` org.
RUN git config url."https://github.com/openedx/django-require.git".insteadOf "https://github.com/edx/django-require.git"
"""
),
(
"openedx-dockerfile-post-python-requirements",
"""
# Make sure to install latest version of `openedx/django-require` for the platform to use. Uninstall existing version 1.0.12 first, then reinstall v2.0.0.
RUN pip uninstall -y django-require
RUN pip install -e git+https://github.com/openedx/django-require.git@v2.0.0#egg=openedx-django-require==2.0.0
),
...
])
The only way that I was able to perform a new Docker image build for openedx on nutmeg was to perform this edx-platform update which is what I’m trying to avoid if possible with the tutor fix that @bryan.w mentions above.
The build error appears to indicate that the git fetch for the particular commit 0c54adb167142383b26ea6b3edecc3211822a776 is not found in the openedx/django-require repo. I performed this manually though and didn’t receive an error on the fetch, so I don’t understand why the tutor patches above wouldn’t work.
@bryan.w fix worked like a charm. I’m not sure why it didn’t work @Zachary_Trabookis , you don’t need to link the whole pip-like URL, just link the primary git URL as mentioned by Bryan. Maybe you forgot to run tutor config save, not sure
edit: @Zachary_Trabookis you’re applying the link in openedx-dockerfile-git-patches-default which will affect only code stage. Please apply it on openedx-dockerfile-minimal to have it on all stages
I’d like to propose “we” create a DEPR for any remaining redirects we still rely upon. I’d like this so that 2U can fork (even temporarily) without having this concern for each additional fork. We’ve already needed to do this temporarily for two MFEs (AuthN and Account), and I have no idea if that needs to be communicated or not.
The trouble is, I don’t have enough information to push the DEPR forward. Is anyone willing to help do the write-up for this?
@robrap seeking some clarity, I know there are some docs on the 2U side for how to go about making these forks. If they get followed, then I don’t think we’ll run into any issues with older releases but maybe the docs aren’t good enough to ensure this? Are you looking for which set of repos you would need to do this on (repos tagged in older releases)?
There is the issue of older tags, which is in a doc, as long as someone is aware of and follows this doc. I’m not sure at what point we no longer need this extra step.
Separately, the question is whether there are still active references using the wrong org anywhere. Or, do we think that’s a thing of the past, except for these tag references?
Lastly, could the references to the old tags be updated as well, or is that not a possibility? Maybe we just work together to find/fix things that are broken if something gets missed in the future?
As far as I know, there is no current code in the openedx org that’s pointing to the older location. If there is, it’s a bug and we just need to fix forward on the openedx side.
Unfortunately, the issue is in versions of tutor/ open edx code that has already been packaged and shipped and those versions can’t be easily updated. I think communication and fixing forward as we fork will be the best steps and we should make sure that the documentation or automation on the 2U side that does fork things back has been sufficiently updated.
As older deployments move to newer releases, this should become less of an issue. Officially, the older versions are not supported but if there are low cost ways that we can keep them running, for now I think we want to do them. Longer term, there may be a time when letting the old versions running is more detrimental than good from a security/reliability perspective but I don’t think that is now.
I think the Python code is clean at this point, but there may be Javascript, Ruby, and dependency file references (not to mention all of the documentation and comments, which are lower priority but still an issue).
With this patch you can solve the problem in nugmet, since I have a platform on 14.1.2 and it has the same problem when creating the image, since it does not find that same commit
When I apply the patch it still doesn’t change the repository.
The first one is a repo that never got forked into the openedx org and so I think we need to figure out a plan for that which will involve some legal confirmation.
Would it make sense to push all of the old named release tags to those “stub” repos? That might help smooth things out for people on older releases. That should be compatible with having the master branch just be an empty “change your URLs” README.
Check the main page of the repo to ensure it still shows the “don’t use this” README.
Re-archive
If this happens to any more repos, we could either create a new stub repo and then push tags like this, or we could just fork into place and wipe out the main/master branch to create the stub.
Hopefully at this point people on older releases should be back to having working git references.
