Decoupling infra upgrades from Open edX upgrades

Currently, we tend to bundle K8s cluster upgrades with Open edX instance upgrades. Part of the reason for this may be that Grove tooling closely ties infra, Open edX instances, and the associated K8s revisions and Open edX releases, which I believe has caused problems in the past(?).

Either way, the infra and Open edX instances are more decoupled now with Launchpad, so we shouldn’t be tied to this any more.

I propose we manage K8s clusters (and possibly other infra) independently to Open edX instance upgrades. Pros:

  • Upgrades for both infra and instances are simpler because there is less changing at once.
  • K8s releases at a higher cadence than the Open edX platform, so upgrading independently avoids needing to upgrade K8s twice when we upgrade Open edX instances.
  • The discovery and testing process for Open edX upgrades can be quicker, as there is less to test and upgrade.
  • K8s upgrades should be less risky and quicker than Open edX upgrades, so should require less discovery and coordination.

This idea could also extend to other infra, such as databases, Harmony, ArgoCD, etc.

I’m not sure how this would look from a planning perspective - perhaps some kind of recurring upgrades epic with tickets for each client?

I’m interested to hear your thoughts! :slight_smile:

Ticket: BB-10943

In my opinion, the issue was how Grove was built. This (decoupling infra from openedx stack) is resolved with Launchpad – as far as I can tell.

1 Like