Wikimedia Release Engineering Team/Deployment pipeline/2017-03-07

From mediawiki.org

2017-03-07[edit]

Who's here:

  • Antoine, Dan, Jean-RenĂŠ, MarkoTyler,

Last Time[edit]

  • Triggering container builds
    • Pushing tags
    • Staging not every build
    • Maybe more discussion needed
  • Nodepool is not the target of our work – will be made obsolete as a consequence of this work in time
  • Docker registry namespacing makes sense for us
    • Moving e2e tests/staging between namespaces

Questions/Actions[edit]

  • N Not done Expand workboard tasks, break out subtasks
    • Could use some help scoping these based on what where we're focusing/who's focusing :)
  • Yes Done Build a jenkins in CI-Staging to test pipeline plugins

Topics[edit]

Does this specification need to cover anything k8s related or should it only be concerned with the building of images (not the running of them)? Unlike the Dockerfile specification, the k8s spec is well thought out and declarative.
    • Talked about last time, I think it's separate from the build step, plugins seem to confirm
    • Dan may have more questions
    • Should we even try to abstract the k8s parts of this?
    • May be too early for this discussion
    • Downsides
      • Ties us to k8s for all time
      • Developers should not have to understand k8s in any detail
      • Limit the things that devs can do with k8s
  • When to build containers?
    • on commit for unit tests
    • on tag for e2e
    • Best case it happens on every commit, but unrealistic with limited resources
    • The longer you wait to integrate changes, the harder it is to pinpoint breaking changes
    • "as frequent as possible"
  • Intermediate e2e testing per commit
    • Testing a commit before merge, test against current staging
  • Mathoid POC
    • Subtasks
    • How the build pipeline works in practice
    • Fully evaluate pearson pipeline, timeboxed
      • throw it all away afterwards
    • talk to labs team, get some sort of k8s infra
    • setup our own k8s cluster
      • Puppet roles are there
      • test env is scrapable
      • may require a lot of manual patches, be a PITA generally
    • Docker compose, Kompose, Minikube, whatever

Puppet stuff

  • Private repo
    • Need a way to inject info into the image
    • secrets, etc should be external to the image

Secret management is an upcoming discussion. Make sure they're not in the build for now.

Scope discussion[edit]

For next time[edit]

As Always[edit]