2020-09-16

Always

Tyler: I have a meeting conflict and can't attend the meeting today, I've asked Dan to run the meeting this week

Jeena has an automation patchset in progress:
- https://gerrit.wikimedia.org/r/c/integration/pipelinelib/+/622231
  - goal: have this happen as part of the pipeline- One nit from alex: It's fine that the pipeline suggests changes, but a human should always be the one +2ing them. if the pipeline is allowed to self-merge a huge attack vector opens up. - Jeena: Yes it is just making a patchset for a human to merge

No feedback on https://phabricator.wikimedia.org/T259817#6395133 - I think joe has left comments already
- One particularly notable comment (clarified by Alex in meeting) is that SRE is not tackling mediawiki-config containization as it requires more domain specific knowledge (e.g RelEng and CPT, other MW teams)
- Moving forward with experimentation

eqiad k8s etcd upgrade done, this removes a blocker for kubernetes upgrades. Hopefully it will be a fast path back to a security supported version
Looking into better supporting the "lambdaoid" approach. The intent is to make it as easy as possible to allow new things to be setup (part of the self-serve architecture anyway)
- What is this for? - Have everything that is in the path of a request
A lot of services in k8s are being migrated to their TLS only endpoints. Mostly transparent to everyone.

API gateway project coming to an end, PET availability will hopefully be increased

Jeena to open task for docker registry specifically for development images
- There is a specific use case already for a team (task?) wanting to build and store a development image for their service, but this leads to a more general question about how and where to store images used only for development purposes (storage requirements being a concern, etc.)
- Differences of opinion around rebuilding dev images locally vs. having a central repository for pre-built images