Wikimedia Release Engineering Team/Local Dev Sync/2019-09-12
2019-09-12 edit
Archives: [1]
Most recent previous planning session: https://etherpad.wikimedia.org/p/local-dev-planning
local-charts interface edit
Done: Test / review CLI stuffs:
- Done License decision: GPLv3
in progress edit
- 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 edit
- 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: