Session
- Track: Local Development and onboarding
- Topic: Local development environment - MediaWiki core
Description
Various local development environments for MediaWiki core have different benefits and drawbacks - what are all of the necessary features (eg: stability, easy setup, production 'parity') that would allow us to standardize on one? How do we get to that place from here?
Questions to answer and discuss
Question: Should there be a single official MediaWiki-core local development environment?
Significance: Deciding how to address the problem of lack of standards
If YES,
Question: To whom should the environment be tailored?
Significance: We can't solve all problems in one environment. We should choose some core things to focus on, and identifying who we are serving will facilitate that.
Question: Which/whose problems should it attempt to solve?
Significance: Decide which issues are most meaningful to the target audience identified above.
If NO,
Question: What should be done instead?
Significance: Find out what the opposition to an official, supported MW-core development environment is, and how we can improve the development experience in other ways.
Regardless,
Question: Which one, if any, of local k8s, mediawiki-docker-dev, and vagrant should we maintain?
Significance: We need to decide whether we should make a commitment to maintaining any of the existing environments in order to move forward with efforts to improve developer productivity.
Related Issues
- T235372 - Wikimedia Technical Conference 2019 Session: Local development environment - complex multi-service Mediawiki development
Pre-reading for all Participants
- https://www.mediawiki.org/wiki/Developer_Satisfaction - Optional if you want to delve deeper into fundamental issues. We will provide a short summary of this and our work to date.
Session Leader(s)
Session Scribes
- Nick
Session Facilitator
- Aubrey
Notes
Slides:
Post-event summary:
- Most people think there should be a single, official MW core dev environment.
- It was agreed that the MediaWiki core local environment should be tailored to basic patch handling or beginner MediaWiki developers.
- People really want to talk about complex development.
- No consensus on what to maintain.
Post-event action items:
- The definition and code for the basic MediaWiki environment should live in the core repo.
- Evaluate the existing development environments to come up with a list of their pros and cons
- Make a decision of whether or not to support SRE use cases (ex: testing different webserver variants)
Detailed notes from Etherpad
Going through slides:
Worked on trying to make "Local-charts" more production-like. Did a proof-of-concept using Minikube.
Once things are merged in master and images is built (using pipeline) and pushed to the image repo.
Problems!
Plagued by complexity, because we tried to make things very configurable.
We think it's not feasible to solve all our use cases with a *single* developer environment, or even to solve these problems in the deveveloper-facing environment at all. Some of these use cases would be better solved elsewhere.
Main topic:
QUESTION: Should there be a *single official* mediawiki core + local developer environment?
Split in two groups! Yes or No. [General feeling in room: 75% yes, 20% No, 5% Undecided/Other]
"Official" being: Release Engineering - standard dev env for mediawiki that we will promote.
Is single official constraint coming from RelEng - and is it because they don't want to maintain multiple dev envs?
We'd prefer to focus our efforts to make one a great success.
It's about whether we should maintain one, and which.
By local dev environemnt, what is that? is it like vagrant, with all the things? or core + extensions and simple deps? Or is that eg the whole wmf cluster with all micro services and data backends --
QUESTION: How do we define the set of extensions/skins in the bundle?
So if I am a new developer on MediaWiki, where do I start? What do i do? MediaWiki core, some basic extensions? If I want to work on abusefilter, all I need is mediawiki core and basic extension support.
QUESTION: Which *one*, if any, of local k8s, mediawiki-docker-dev, and vagrant shold we maintain?
"Yes group" discussion:
Florian: What do i do now? I have this task here, it says just fix this translation or something, how do I test that? It just needs mediawiki, php, webserver and thats about it.
Z, I talked to a outreachy student, and they said that the hardest thing about the whole project was installing mediawiki to get going
Z, Who has tried local charts (some people put hands up), its just 5 ot 6 commands to get everything setup
F: how long does it take? Vagrant takes a long time
J: probably less than vagrant, still need to download a lot of code/images
Z: probably depends on your OS, dependson on if a VM is needed etc on how much is needed.
Ricardo: what do we do right now for onboarding develoeprs in different teams
all: not much
Andre: we do have a wiki page for that
BD: it did say use mediawiki vagrant, then community decided that vagrant wasnt working for them and added different things
J: they found that vagrant wasn't good for their use cases
F: which ones?
Kosta: it didn't work for me, something didn't work with NFS, for who it should be tailored: new developers, should be fast and basic. MW-V's strength was the complexity it could handle
Florian: Thats probably an advanced use case
A: If we target just new developers, will we end up using it?
James F, no that is tommorrow ssession (complex environments)
A: if we don't use it we won't be dogfooding
Moritz: That was the question with vagrant, but noone used it? Bugs were not fixed?
James: Noone used it and tried to make it mimic production
BD: search did, really hard to make it mimic production entirely.
Gergo: .... the flexibility of vagrant could be captured in docker if you had a system of creating envs based on a config like vagrant
Kosta: About dogfooding, I would use the simple environemnt, sometimes i use homebrew system sometimes, sometimes I use the docker-compose thing, generally the simple environemtns work for 99% of situations.Same system locally and for CI
Forian: Have we answered "To whom hould it be taylored". Beginners. Core+extensions plus a bit
James F: you cant test central auth unless oyu ave a multi wiki setup, you cant test X unless you have Y
Gergo: new developer use case, simple. Other is new sysadmin setting up a production wiki for a simple use. For these both local and production are close to the same.
Florian: Does iut need to? in production there are far more requirements than for locally.
Gergo: config layers for different services. Do we want to support both use cases with the same system?
Z: I wanted to answer the question of if i would use it, and I have used them all. I would use it (simple one) defintly. At least for my usecase it would work.
Lars: there's about 15 different use cases in this group. Trying to solve all at once is difficult. Concentrate on a solveable problem.
Z: So you vote for lets do the simple thing?
Lars: What is the simpliest thing we can do and how can we make it more simple?
F + JamesF +Z: the simplest would be 1 wiki with some extensions if you want to, maybe a skin
Daniel: why can't I just go to WMCS, click an instance and it built ready for me
Lars: From my understanding of this, is that it is not local, it's local to "you"
Adam: with mediawiki docker-dev there's no reason it can't run on EC2 or whatever
J: vagrant works on toollabs as well
Lars: we could let everyon hack in production??
Daniel: installing mediawiki and a few extension doesn't seem very complex in puppet, package+role+an instance. What's the advantage of running it on a local machine?
J: using puppet is like running a 100m race in a tank
A: who should it be tailored to? include people who don't have the internet reliably
K: local dev config in the mwcore repo. Start with baseline: 1) it should run MW. 2) extension 3) parsoid. Weakness of existing solutions is the separateness of mwcore repo.
Z: there is no reason that they have to be
"Yes group" summary:
- Target beginners who are working on core and a few, simple extensions plus a bit?
- Environment config should live in the core MW repo so that it gets updated in lock-step with MediaWiki itself.
- Shouldn't be exclusively focussed on running in the cloud, also include low Internet use cases.
"No group" discussion:
- Single solution quickly becomes unmanagebly complex. Depends what you're working on, extensions, core, gadgets, etc.
- INFO: Singular solution will inevitably become too complex.
- Should there be a single env? no. But should there be a single tool? yes. With different configurations and variables.
Perhaps implementation detail, e.g. vagrant has it, but problematic because all contained, still have to install
e.g. one env for standard git core. one with no runtime sharing, -- difficulties with
If we only have a single configuration, you're only going to find bugs that exist in that env.
INFO: Should be a recommended single solution, but alternatives should be available.
QUESTION: k8s future. Current situtaion seems to be that multiple solutions are supported.
T: Different installer runtimes vs dev envs. Apache and Vagrant.
S: if we make a decision about the software
T: If wemake a breaking change, and doesn't affect you if not using k8s
S: If there is a single dev env, there isa seperate thing.
P: Some people simply refuse to use certain envs..
P: If we make one dev env, we'll make it inhouse, that might be very diffciutl to change in the future. Do we want to tie ourselves to k8s/docker.
INFO: Singular tools are often built inhouse and often black boxes.
QUESTION: use-case that keeps coming up - for a dev, installing it yourself is the preferred outcome. With the docker it's a bit lower level, adding config myself and thus i learn how to debug it which is good, however, then it potentially requires QA and PM to also use same/similar config.
S: beta-cluster is where QA happens
A: releng and some staff devs need the same env as beta staging test production, same database/schema/etc.
INFO: 2 different solutions needed. 1 for staff devs, 1 for newcomer/volunteer. How do we get there, minikube currently broken
INFO: Gitlab has a good automated workflow, automaticaly create temporary clones of beta cluster, -- compromise/con: can't run offline
E: We should narrow down 1 by 1 from the existing multitude, rather than deciding on a single one now/today. Incremental approach.
"No group" summary:
- one custom solution, usually custom built on top of existing technologies
- most non-dev use-cases (PM/QA) point to a single tool for all. vs dev who will often have multiple tools interconnected
- Need a more singular solution for non-dev use-case, and configurable sol
- devs working on different environemnts, helps surface issues
- Singular tools are often built in house, and are often black boxes
Final question, which one (if any) of X Y Z should we maintain?
BD: vagrant is better documented, and more widely installed. But it does need care and feeding. Problem: primary maintainer (me) hasn't been a highly active developer of mediawiki itself for a few years.
BB: should we just invest more here? and stop looking for alternatives?
BD: This is the case that I have been making for the last years, yes.
GG: Parity. "Is it close enough to production". Can vagrant be?
JF: Should we split mw vagrant into a simple thing and a complex thing. Lean and simple, vs production like thing
BD: In theroy the roles system does that, but in practise maybe it doesnt
GT: the model of docker is make a system, take snapshot, [???]. Model of vagrant is [???] - technically inferior to docker. However I like the role system and want that in docker.
Z: my question was, is vagrant itself supported upstream? if vagrant might just go away, should we invest effort there?
GT: Is upstream a problem? In breakages the problem is rarely vagrant itself.
SR: They have does things like break on point releases numerous times
Z: They did change the config on a point release and break things before
BD: Do you expect minikube to keep working and not break down the line?
BB: We've had frstrations trying to work with minikube
TT: I'm in the middle. Support how vagrant works, ease of use, model, good for QA. Other tools that emerge have been workaround for issues with vagrant. Are those issues fixable, or inherent? For example: setup time (took me 45-60 mins to get up and running on a fast machine). If something goes wrong, and needs updates, my transition to the new state might not have been tested [?]. But with docker, I can teardown and rebuild in a few minutes.
R: In theory you could do that with vagrant images, and package the stuff in it, rather than building it when people download and install etc
KH: insights being made into the pros/cons of these 3, and we should write down a specific list, for the 2 audiences (daily professional versus occasional contributor?). Start with a minimal core.
Moritz: Should discuss exactly what we want to achieve. Docker for me was easier to setup on my own and change on my own.
PM: I have 3 environments i use: 1 docker, 1 vagrant-lite, and 1 vagrant-max (restbase parser drains battery fast).
R: Thats not vagrant's fault though
BD: But it is a usecase thing. Thats probably the most important thing for us to be concetrating on.
F: I think we all agreed that, We should put whatever we are using in the repo of mw core. Easier to maintain, more visible,
AM: Is there any altrnative to minikube?
AS: minikube doesn't work for me, but plain k8s does
AM: do we have contacts with upstream? Is that google? We need to be able to spinup a dev env that is close to production cluster, can you help us do that?
BB: I dont have contact with upstream:
BD: the WMF is a member of the CNCF which is the owner of k8s.
AS: Why are we doing k8s? theoretically because we're going to tht in production, but that's a longterm project, so currently it's added complexity
GG: Action items, usecase creation and analysis evaluation would make sense. K8s? One thing we did learn and want to avoid, is just doing it in production. This is why beta sucks, is because it never became a real part of the pipeline to getting code to production. So we want to have the whole pipeline to be unified, not skipping them on purpose.
Moritz: Hire a software maintainer that supports it for 4-5 years?
AM: There is one thing i love in vagrant, that you can enable roles. If you want to fix search, just enable the search role. As a dev, i just want to work on a single extension, and not worry about all the peripheral services etc.
PM: People mention parity between prod and QA, but i dont think we need that. Xdebug, really slows down a lot, but QA and product manager dont need that, so already there is no parity.
Akoris: What happens when you have to debug stuff?
PM: Usually QA person can verify that on a different type of environment
TG: need to make sure you don't break things related to cluster. Setup a repo, and ability of vagrant to pick the things you want to run, and not the others. I'd like a system that is known to work for testing in production.
Akoriss: the roles thing is our creation, not built into vagrant. Lets have an action item maintaining that roles thing no matter what our environment is
JF: Action item: for people: this test stack is meant to test things we're deploying to production or 3rd parties. Note: PHP versions. It should meet the needs of DBAs
GG: Not only use the local dev environemnt for new php app level code, but also use it for system level changes as well
JF: or... dont care, and dont make so much effort.
Tyler: make the deciion of whether or not to support SRE use-cases as well as developer use-cases. (ACTION)
....
TT: I think the CI usecase is close enough to the .... One of the things that we do in CI is test against multiple PHP versions. Implys that webserver and PHP version is plugable at some level. One thing i like, is if someone report s bug that only affects PHP v 7.4, i can do that in docker. It's still plain mediawiki, it's just different flavours of plain. E.g. testing nginx, which is something we currently support, and need to be able to test.
(It's TIME!)
Action items:
- Whatever it is, put it as close to mediawiki core as possible (in the same git repo).
- Dogfooding is important
- related to promotion, and whatever is well-documented will be likely to be used.
- Usecase creation and analysis evaluation.
- Avoid only in production. [Unclear what this means]
- Keep the idea of Roles, no matter what our dev environment ends up being.
- Make the decision of whether or not to support SRE use-cases as well as developer use-cases.Originally from https://etherpad.wikimedia.org/p/WMTC19-T234632