Move off of edxops DockerHub org images

[kdmccormick]

Context

This issue is the successor of a private issue: https://github.com/openedx/decoupling/issues/58

Currently, Devstack's service images are hosted in the edxops DockerHub org. Considering devstack as a community tool, this is not ideal for three reasons:

• edxops itself is owned by edX,
• the images in edxops are built on an edX-managed Jenkins instance, and
• the images themselves are built using Ansible and provisioned using Ansible and Paver, which is bad for developer experience.

Acceptance Criteria

• Ensure that the Open edX community does not depend on edX for building or hosting Docker images.
• Write up tasks to clean up any remaining artifacts once the first task has been achieved, including but not limited to:
  • GitHub actions that push images we don't use any more.
  • Jenkins DSL scripts and jobs for images we don't need any more.
  • Devstack toggles and provisioning code paths related to experimental images.
  • Unused Dockerfiles, their assets, and scripts that exist to support their images' use in devstack.

Potential Approaches

A combination of these approaches may be warranted.

1: Build the Ansible/Paver-based images using GitHub Actions and push them into the openedx DockerHub org.

This succeeds in removing our dependency on edX's DockerHub account and edX's build server. However, it means we'd still be using the non-ideal Ansible-baked images. Worse, we'd be tainting the openedx DockerHub organization with the Ansible images, which seems like a bit of a step backwards architecturally.

2: Switch devstack to the experimental Ansible-free images from the openedx DockerHub org.

There are Dockerfiles checked into most service repos, which currently auto-push mostly-unsued yet idiomatic and Ansible-free images into the openedx DockerHub org. We could switch devstack over from the edxops images to these existing openedx images, with some modifications to ensure that they new images work with devstack. This is harder than Approach 1 but would presumably be beneficial for devstack users and the containerization effort in general.

3: Declare we're dropping devstack in favor of Tutor

The build-test-release WG has already decided that Tutor is the one-and-only community-supported installation method for Open edX. Although edX and some other community members still use devstack heavily, Tutor also seems to be the predominant development stack. If we felt that deprecating devstack in favor of Tutor was the right move, then the transition off of the edxops images be coupled to the transition to Tutor.

As for the openedx DockerHub org, we'd either shut it down, or perhaps make it a mirror for Tutor images.

This effort required to achieve this is captured in a platform roadmap item: Enhance Tutor so that it may replace Devstack.

Status

Dec 2021

I'm trying out Approach 2 for edx-platform and credentials. Relevant PRs:

• https://github.com/edx/devstack/pull/866
• https://github.com/edx/edx-platform/pull/29549
• build: tweak dockerfile; build and push both base and dev images openedx/credentials#1510

Jan 2022

We are putting down Approach 2 in favor of focusing our energy on Approach 3 (replace devstack with tutor).

[kdmccormick]

Marking this as Blocked. We are starting openedx/platform-roadmap#11 (Approach 3, in this issue). If the project starts off well, I will close in favor of the Tutor initiative.

[kdmccormick]

Closing in favor of openedx/platform-roadmap#11