Arch Tea Time: 2020-05-07 (Microbachelors, Devstack)

Owned by Nimisha Asthagiri (Deactivated)
Last updated: May 14, 2020
4 min read

Topics

  • MicroBachelors

  • Devstack

What we plan to ask Microbachelors learners:

  • Ask @crice (Deactivated) , @Albert (AJ) St. Aubin (Deactivated) , @Ryan O'Connell if you have questions

Devstack

Bill:

  • There’s a lot of work/conversation going on about devstack and how we deploy to prod generally (and the Open edX community), what’s shared, what’s not, etc.

  • We are moving towards containerization. Devstack implications (caveat: none of this is decided. Directional vision, looking for feedback):

    • Proposing that every repo has its own docker-compose file, provision script.

    • For a given IDA, you can do “docker-compose up” and the IDA you’re working on comes up, along with its dependencies.

    • Centralized devstack owned by (heroes in hero mode)/nobody. Decentralized helps to promote team ownership. Avoid the things you don’t need (e.g. programs provisioning).

    • Centralized ownership still needed for some things like integration testing.

  • Where are the holes? What are the bits we’d need to address for something like this to move forward?

    • AJ: I want to like it being distributed, but concerned that some things will become harder (like seeding data). How do we make it so that it doesn’t have to be replicated? There are also certain things we’ve added to provisioning to get developers off the ground quickly (e.g. marketing site setup). We’ve also added publisher to our stack to encourage people to create data that’s more true to our production experience. Some of these things are easier when things are centralized, and we might lose this. (Flagging as concern, not looking for solution right now.)

      • Adam B: Have split up how we deploy things in prod/sandbox/etc. and have come across some of these issues. Easier to keep one thing consistent than a bunch of things consistent.

      • Bill: If you’re provisioning the bits you need for credentials, you don’t want to have to recreate all the LMS stuff in your script because your app depends on the LMS. Shared interface for every app having its own bootstrap script and maybe part of your system’s bootstrap process is to call others bootstrap scripts? Definitely edge cases there, and ability to negatively impact other teams.

    • Nimisha: Does everyone understand the vision? Can we collectively identify problems, not go into solutions. We can see which things haven’t been thought about.

    • Clarifying questions

      • Emma: Are we going to divide on a team by team basis? One docker compose for each squad to maintain? Or repo-specific? Service-specific? Is the squad maintaining all the specific bits?

        • Fred: The goal would be that each service has dev environment that would bring up its dependencies. Wherever you’re making changes.

          • Emma: So frontend-app-payment would have different environment than the ecommerce service? If I wanted to make a change that adds url_parameter in ecom when we redirect to the microfrontend, I would have to stand up two services?

            • Fred: Stand up combination of the dev environments?

            • 1 docker-compose for ecommerce, 1 for frontend-payments, 1 for both?

            • Emma: Could have many combinations in theory. What if I needed LMS and ecommerce and frontend-app-payment?

            • Fred: Trying to get this kind of information from devs. We know its not everything, but in what combos?

            • Feanil: We’ve tried the everything in one place, not happy with it. One single service at a time is a possibility. Do we want to take on the complexity of the middle ground where we explicitly map out the dependencies?

            • Adam B: Note: we have started to take on the complexity for this in the Enterprise and Sustaining teams already.

            • Nimisha: Don’t necessarily have to make every possible combination, but a more used subset. E.g. might have frontend-app-payment + ecommerce all the time for your team.

            • Feanil: Points out that we probably want to be able to bring up API + MFE as a common use case.

      • AJ: Can we centralize repo for devstack but split ownership?

        • Nimisha: High level ownership at the Theme level? Groupings like Authoring / Learning / Discovery / Enterprise / Programs / etc.?

      • Kyle: You don’t need a docker-compose file for each dev environment. You can have one file that brings up subsets of those services. We don’t need to have a compose file for every possible combination.

      • DaveO: Dev mode vs prod mode in devstack?

        • gunicorn, come up faster, no file watching, remote debugging, etc.

        • Right now, very slow with Ansible - since we bring everything up.

        • David Joy: How do you switch between the two?

          • Different images?

      • Kyle: If two dev envs need LMS, is that the same LMS or different instances of the LMS?

        • Bill/Fred: Probably shared? Haven’t worked it out. Stubbing some parts of the LMS out? Want to avoid standing up the LMS as part of most people’s devstack.

        • Adam B: Spinning up multiple LMS instances on a laptop is pretty tough. Might spin up external sandboxes.

        • AJ: Would like to be able to run everything locally. Would love to have sandboxes to be the same thing as devstack. (++)

  • How might we accelerate this effort?

  • Anticipated problems (what may be harder and will need an alternative solution once it’s decentralized)

    • Cross-service dependencies

    • How do we provision data?

      • Jeremy: We do have OEP-37 for test data, but we haven’t implemented it yet

    • How will sandboxes be setup and provisioned?