Change Details

In T384944, we experimented with an HTTP routing implementation that allows fine grained control over the pod group that serves an HTTP MediaWiki request. While the experimentation and PoC was successful (docs are at https://wikitech.wikimedia.org/wiki/Single_Version_MediaWiki and child pages), there are a number of leftovers. First among them is making the JobQueue system compatible. This is what this task is about # Plan ## Host header The MediaWiki Single Version relies on the `Host` HTTP header to achieve the routing. First part of the plan is to make the jobqueue send those host headers. Currently the workloads serving the jobqueue are single VirtualHost MediaWiki pods, named collectively `mw-jobrunner`. Given the single VirtualHost and the default behavior of Apache to choose the last VirtualHost is nothing else matches, adding the Host header to every request should be a NOOP. We will utilize the `staging` environment to prove that and then enable it everywhere. ## Routing to the proper set of pods The next part would be route the requests to the proper group of pods. For this, we will need to configure the jobqueue change-propagation installation to allow to vary per wiki the endpoint that jobs are being sent to.

In T384944, we experimented with an HTTP routing implementation that allows fine grained control over the pod group that serves an HTTP MediaWiki request. While the experimentation and PoC was successful (docs are at https://wikitech.wikimedia.org/wiki/Single_Version_MediaWiki and child pages), there are a number of leftovers. First among them is making the JobQueue system compatible. This is what this task is about # Plan - [x] Host Header - [ ] Route to the proper set of pods ## Host header The MediaWiki Single Version relies on the `Host` HTTP header to achieve the routing. First part of the plan is to make the jobqueue send those host headers. Currently the workloads serving the jobqueue are single VirtualHost MediaWiki pods, named collectively `mw-jobrunner`. Given the single VirtualHost and the default behavior of Apache to choose the last VirtualHost is nothing else matches, adding the Host header to every request should be a NOOP. We will utilize the `staging` environment to prove that and then enable it everywhere. ## Routing to the proper set of pods The next part would be route the requests to the proper group of pods. For this, we will need to configure the jobqueue change-propagation installation to allow to vary per wiki the endpoint that jobs are being sent to.

In T384944, we experimented with an HTTP routing implementation that allows fine grained control over the pod group that serves an HTTP MediaWiki request. While the experimentation and PoC was successful (docs are at https://wikitech.wikimedia.org/wiki/Single_Version_MediaWiki and child pages), there are a number of leftovers. First among them is making the JobQueue system compatible. This is what this task is about # Plan - [x] Host Header - [ ] Route to the proper set of pods ## Host header The MediaWiki Single Version relies on the `Host` HTTP header to achieve the routing. First part of the plan is to make the jobqueue send those host headers. Currently the workloads serving the jobqueue are single VirtualHost MediaWiki pods, named collectively `mw-jobrunner`. Given the single VirtualHost and the default behavior of Apache to choose the last VirtualHost is nothing else matches, adding the Host header to every request should be a NOOP. We will utilize the `staging` environment to prove that and then enable it everywhere. ## Routing to the proper set of pods The next part would be route the requests to the proper group of pods. For this, we will need to configure the jobqueue change-propagation installation to allow to vary per wiki the endpoint that jobs are being sent to.