Wikimedia Release Engineering Team/Local Dev Sync/2019-09-12

= 2019-09-12 =

Archives:

Most recent previous planning session: https://etherpad.wikimedia.org/p/local-dev-planning

local-charts interface

 * ✅: Test / review CLI stuffs:
 * Skeleton go-based cli
 * adding the start command and managing minikube
 * ✅ License decision: GPLv3

in progress

 * mediawiki/core on Apache + FPM
 * 525972 (WIP): [DNM[WIP] Add .pipeline/ with dev image variant]
 * 535342 (WIP): mediawiki-dev: port 8080; apache entrypoint
 * 525842 (WIP): mediawiki: replace with blubber-compatible Apache + FPM image
 * Fixing up restbase chart https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/517557

planning / general direction discussion

 * Jeena sent an email
 * After gathering feedback, I would usually want to brainstorm with the stakeholders on solutions, but didn't really do that for the local development environment feedback because I felt pressure to just get started. Do you think we should try that? Or do we just need to prioritize our work a little differently?
 * Mukunda sent an email
 * Without user feedback we're working in a vaccuum -- hard to be responsive to users that we don't have


 * J: Without CI we don't have a way to get updated images -- this is an important part of our environment -- getting resource to deploy those somewhere (which may be difficult). A cloud hosted environment where merged images get deployed would make things easier.
 * (Q) J: People don't have a way to run things locally, people don't have a way to run things in a shared environment
 * J: Focusing on CI is important
 * B: cf: line 16 -- this should work -- although finicky in a bunch of little ways. I don't know if that's CI/Pipeline or Minikube, etc. Agree: CI generation of images is a reasonable thing to be focusing on
 * (Q) M: Balance between generated images + source-code user provides
 * M: I feel like current work is close to being usable
 * J: I feel like everything is broken
 * (Q) B: My feeling is that the current solution is hard to work on -- factoring out to more shared code means I'm looking at 4 different repositories -- it's not easy to reason about as a developer
 * M: Same experience
 * J: Trying to make things easily configurable has made things hard to work on/hard to make changes
 * M: Needs a giant refactoring
 * J: Not sure what to refactor
 * B: Reconsider the solution from first principals -- rethink some of the tools we're using -- I spun up mediawiki-docker-dev before this meeting and it took 10 minutes -- in contrast to what we have now, I don't know if we'll get to this level of ease
 * J: when our project was working, I don't think it even took 10 minutes
 * M: Running the install script failed on Ubuntu, but worked first-try on Debian, so it did work (other than huge downloads)
 * (Q) J: Internal struggle of having everything installed for the user vs control for the developer?
 * M: DeviantArt VirtalBox + Parallels --> pairity with each other vs pairity with production
 * B: SparkFun had identical VMs -- worked very well in the same way as DeviantArt. What about a qcow2 image that you could run just wherever.
 * J: An image for your whole ecosystem?
 * B: Run locally, run on a VPS, Compute system provided
 * (Q) J: What is the something you run? The whole env, or each service?
 * B: There are many ways to approach it
 * (Q) M: I am no fan of K8s
 * B: Will co-sign ^
 * J: Docker, too?
 * M,B: Less so with Docker
 * M: Docker swarm seems bad
 * J: I haven't ever used *just* Docker
 * J: k8s in GKE is fine, minikube: I have a lot of issues -- just getting things to talk to eachother has been a stuggle
 * B: Independent of anything: I think minikube is buggy software -- we should think about something besides minikube
 * M: Agree, it doesn't seem to get a lot of support even though it's part of k8s
 * B: Minikube has made my electric bill go up
 * M: K3s is decent, but bare metal, but we could roll our own VM. Minikube doesn't do much for us.
 * (Q) J: So if you're running your own VM, how does that interact with your host machine?
 * T: Questions from the email...
 * M: Who are the stakeholders?
 * J: Do we want to have a hangout meeting? Or have anyone we want to show up?


 * T: things marked with Q need to be decided


 * J: how much should an environment do for you?
 * M: Providing a clean framework to build on top of would be my strategy
 * B: what do users want out of this?

- There're survey results - We can ask other questions if need be


 * GDoc for open questions:
 * https://docs.google.com/document/d/13IFbDoAptfCwyM-oJkmQoUCU3xfNoCviTElUxoPHDhM/edit?usp=sharing