2022-05-04 DevEnv Meeting notes

Owned by Rebecca Graber (Deactivated)
Last updated: May 04, 2022
3 min read

 Date

May 4, 2022

 Participants

  • @Rebecca Graber (Deactivated)

  • @Zach Hancock (Deactivated)

  • @John Nagro (Deactivated)

  • @Alexander Sheehan (Deactivated)

 Goals

  • Share updates, remove blockers

  • Determine a good way forward on the mysql patch for devstack on M1s

Item

Notes

Item

Notes

Updates

Becca:

  • working on turning the course-generator into a local plugin

Zach:

  • planning to ask about the plan for discovery (which is still v0)

Alex:

  • went to Open edX! Woo!

  • Saying hi :)

  • Migrating catalogs from platform to other services is awful and only one-directional, which is silly (eg platform catalog to enterprise catalog)

John:

  • Focused on the devstack-M1 compatibility PR as part of helping new hires

  • Documenting known fixes in case we run into similar issues with Tutor

M1 Devstack

One of the key impediments with devstack on M1s is the pin to MySQL 5.7 and there is no mysql-57 docker image that works on ARM, so we’ve been experimenting with using MySQL 8.

Upgrading prod to MySQL 8 is going to take a while.

We can either force an upgrade or make it an option in devstack (similar to Tutor).

Conversation points:

  • Devstack is not really that close to prod anyway

  • We have a decent amount of CI around mysql

  • The worry is making a change that works locally but hoses production

  • Could we add CI checks that check mysql 5.7 on PRs.

    • Is this already a thing?

    • @John Nagro (Deactivated) to chase this down

    • @Rebecca Graber (Deactivated) to bring this up in archbom as a fait-accompli-unless-you-yell

  • Some MFEs are having issues on M1 as well

  • Is there a way we can ensure we don’t blow away people’s local data when they upgrade? The data is stored on a volume literally named ‘mysql5.7’

    • We would want a robust and tested process to help people migrate (having both available and a process to move from one to the other)

 

Plugins

We have a non-obvious docker compose file for every additional piece you need to set up to make it work for 2u. This makes onboarding deeply annoying.

A plugin might be a good solution to combine all these little steps.

Thoughts:

  • we want to make it pretty opinionated for 2u people to make sure we all have the same setup

  • could we make it easier to not have to check out everything?

  • how do we contribute to the community at the same time?

  • an onboarding plugin could basically just run the command line that installs the repos and plugins we care about, even giving us dev versions of the plugins

  • a sandbox organization/repo where we can share code?

Further discussion

  • There’s probably going to be a common set of services mounted, set up steps, and likely data generation where we can make a bunch of assumptions about what a 2U developer needs. Would we want to build a 2U specific onboarding plugin? Or, should we try to keep everything we do generic enough so we are contributing back to the community?

  • Who owns plugins and the fixes for them?

    • Right now Regis pretty much owns the plugins

    • We pip install things locally

Decisions

@John Nagro (Deactivated) will move forward with assuming we’re just going to upgrade devstack to mysql8 in his PR, @Rebecca Graber (Deactivated) will inform ARCHBOM and see if anyone screams

With the caveat that we will try to leave 5.7 data intact

@Rebecca Graber (Deactivated) to make a plugins folder in the devenv-wg repo so we can start throwing spaghetti at the wall