Arch Lunch: 2019-10-24

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 itemCory 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
    •  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 ItemNimisha 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?