A testing environment for something like webservice might take an interesting bit of magic to make work quickly, but it would help any contributor (including toolforge admins) work on it more efficiently.
Ideas are things like a docker-compose or some kind of vagrant setup, perhaps.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T220020 Action items and work for retro 20190403 | |||
| Open | None | T220053 Build a dev/testing environment for webservice that would make it easier to get people involved in fixes | |||
| In Progress | None | T326789 Toolforge: improve local kubernetes development setup | |||
| Resolved | dcaro | T338153 toolforge lima-kilo: toolforge-jobs fails to run because it can't create log files | |||
| Resolved | aborrero | T338156 toolforge lima-kilo: fails to install because updated volume-admission-controller URL | |||
| Resolved | aborrero | T338158 toolforge lima-kilo: fails to install because api-gateway fails to deploy |
Related, but not quite the same thing: T157733: Create developer environment using Docker images from Tool Labs Kubernetes
I recently did this in a tool to make testing some major changes to webservice shell easier:
$ cd $HOME $ python3 -m venv venv.bastion $ source venv.bastion/bin/activate $ echo 'source $HOME/venv.bastion/bin/activate' >> $HOME/.profile $ pip3 install -U pip wheel $ git clone https://gerrit.wikimedia.org/r/operations/software/tools-webservice $ pip3 install -e $HOME/tools-webservice
After applying all of this, which webservice finds the version in $HOME/venv.bastion/bin first. That file is a stub that loads and executes the contents of $HOME/tools-webservice/scripts/webservice. Edits to files in $HOME/tools-webservice are live immediately. I think this is basically the same thing that @Bstorm has been doing for a while to test webservice changes in toolsbeta.
The only part of working on webservice this does not support testing is changes to the webservice-runner script which is embedded in the Docker images. I think we are stuck with that unless we make some deeper changes in how the pods launched by webservice work. We might be able to do something interesting using init containers if we wanted to fix this last bit. The general idea I have for that is that we could stop putting webservice-runner (and the rest of the webservice code base) into our container images directly. Instead we could use an init container to populate a Volume that is mounted into the main container and used from there. This could have other benefits for easing deploys of webservice too, but would take a bunch of testing. But if we had that, we could also have some "developer mode" feature that would let you swap out the normal init container for one that instead injected your locally modified versions into the pod.