Action Items

Topics

• Should we invest in improving devstack? ++++

  • Makefile wraps docker-compose

  • Pains today:

    • make pull pulls down all the images

    • Makefile rules can be more discoverable

  • Future work on Kubernetes

  • What if each repo owned their own docker compose files?

  • Notes repo

    • Has its own helm chart

      • has its own dev.yml

    • Can use this is as a model

    • Devops proposal

      • Then, try Skaffold

        • manages lifetime of a container so don't need to rebuild

      • Looked at draft compared to Skaffold

  • Service owners can replicate a model that the devOps team comes forward with as a proposal

  • Q: How can DevOps get input from application developers on their proposed solutions?

    • POC in Notes

    • Pilot with an application team for a few weeks or a quarter before rolling out

      • FWIW, Blockstore is small and not even in devstack yet.

  • Break up into 3 ways:

    • Quick wins on Devstack

      • Whoever is able to, do these. Raise complaints about them.

        • Update migrations cache

        • De-tangle provisioning

        • Make README more consistent

      • Action item - Make/choose a place to catalog these issues @Jeremy Bowman (Deactivated)

    • Update services to not depend on Ansible, etc.

      • Moving off ansible into well-layered Dockerfiles seems like a specific step (possibly w/ substeps) that could happen incrementally both depthwise and breadthwise

      • Action item - Look at Blockstore for this @Adam Blackwell (Deactivated)

      • As time permits Action Item - Try this with e-commerce @Calen Pennington (Deactivated)

        • Pulling docker file into the repo

        • Pull steps out of Ansible and into docker

      • Action item - @Cory Lee (Deactivated) will take this back to BillD

    • Next-generation that relies on Kubernetes++

• Now that API doc tooling is merged, how do we want to start improving the docs? ++

  • See https://courses.edx.org/api-docs/

  • Swagger is pulling docs from comments, args, etc.

  • REST API Conventions exist today

    • Action Item - Update these conventions with the API documentation best practice. @Kyle McCormick (Deactivated), @Ned Batchelder (Deactivated)

  •  Ideas:

    • Doc-athon to update REST APIs

      • Can prioritize according to what teams understand

      • Or prioritize according to what's publicly supported?

  • Currently, decided to limit to APIs under the /api sub-path

  • Action Item - @Nimisha Asthagiri (Deactivated) gather input and prioritize Arch Backend needs

• Why is/will be upgrading our Ubuntu and Docker AMIs/images to Bionic or Focal hard? +

• Where do we track issues? Is there a consistent scheme for libraries/services/frontends? Do we need one?