Wikimedia Release Engineering Team/Local Dev Sync/2020-05-21

Discussion
This is a cool idea Mukunda: it would be cool if there are directories which define sets of commands and services, that directory could exist in a repo full of other commands or in a repo along with the mediawiki extension so essentially the cli needs a good discovery mechanism Adam: Yes Brennen: We should have a task to evaluate this Jeena: I don't think we should get bogged down in trying to determine if something is good enough and never do anything Adam: I could add it to mw-cli behind a feature flag and you could try it Brennen: The idea of the cli is to be able to put different things behind subcommands Mukunda: Plan to mock it out in stubs and maybe we can fill out some stuff
 * Combine mediawiki-docker-dev / mediawiki-docker efforts? (???)
 * Adam: Decided to rewrite how mediawiki-docker-dev worked on Tuesday
 * More flexible roles, etc.
 * On Wednesday got an e-mail about evaluating developer environments, tried real hard to make mw-docker-dev work...
 * Tried out mw-docker stuff and mwcli stuff.
 * Think maybe mwcli stuff could take over mw-docker-dev, but there are good learnings from mw-docker-dev that could feed in.
 * Adam:  My dream is that there's a CLI that lets you interact with these docker-compose elements in various repos and just pulls it together.
 * Jeena: Think people will be resistant to docker-compose files in other repos?
 * Adam: I don't think we should be too worried.  There's some flexibility.
 * James: Thoughts:
 * Average mw extension is pretty boring and samey.  Maybe we have a fallback setting where we don't need to add files.
 * The other side of that is that fanning out to individual repos gives those repos control, which is both good and bad.  Hard to tie things together for CI purposes.
 * Say Parsoid changes its entrypoint - they then need to change their docker-compose fragment...
 * Potentially an inversion of dependency principle.
 * The other benefit of centralizing everything is that it's easier to land a change of configuration in a single go.
 * Adam: Had another thought - if you want to use multiple docker-compose files together, they need to be the same version.
 * James: Naming convention for files?
 * Brennen, Mukunda: What if most files for docker-compose live in the cli and overrides are in the repo
 * James: We've thought of docker as a lightweight solution where you don't have to stand up things like elastic search and redis. Now we're talking about doing that. I would love to combine efforts, but don't want mediawiki-docker to become bloated and slow, or taking over mediawiki-docker-dev and changing it for the worse
 * Mukunda: so essentially the cli would have a list of places to look for compose files and you can add more to it by running a command? and each repo could have a hook that runs on install if you want to do fancy stuff
 * Adam:  yus, you need something like that, and generic other scripts to help you do things,
 * James: Also please tear down script entry points, not just install ones.
 * Adam: Currently first I "just" need to implement what's happening in docker-dev in mediawiki-cli, then we could see what we think about it
 * [demo]
 * Side question: Could install.php have an option to not create LocalSettings.php?
 * Side note: We should make sure to create "official" images where needed


 * https://github.com/ubuntu/microk8s

Action items:

 * Adam: mock-up/outline docker-dev in mw-cli
 * Adam: Write a ticket for releng to evaluate what is currenlty in v1 branch of mediawiki-docker-dev (for what? CI?)
 * Mukunda: Write out a ticket tree of things we want? (!?)
 * https://phabricator.wikimedia.org/project/view/4585/
 * https://phabricator.wikimedia.org/T253313

Previous action items

 * Jeena & Brennen to hack on TMH stuff during today's EngProd hackathon.
 * Re: Docker image stats - James says this can maybe be pulled out of Hue.
 * https://wikitech.wikimedia.org/wiki/Analytics/Cluster/Hue