Page MenuHomePhabricator

Migrate www.wikipedia.org (and other www portals) to be its own service
Open, Needs TriagePublic

Event Timeline

hashar added a subscriber: Jdrewniak.

I had a quick talk about this with @Jdrewniak . If we the blubber/pipeline thing setup, that will address T213806 for sure. And this task would then be completed once the service gets migrated to Kubernetes.

Change 569694 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[integration/config@master] layout: [wikimedia/portals] Add service-pipeline configuration

https://gerrit.wikimedia.org/r/569694

Change 569694 merged by jenkins-bot:
[integration/config@master] layout: [wikimedia/portals] Add service-pipeline configuration

https://gerrit.wikimedia.org/r/569694

Mentioned in SAL (#wikimedia-releng) [2020-02-04T01:56:31Z] <James_F> Zuul: [wikimedia/portals] Add service-pipeline configuration T238747

Per Tyler, we need a production-suitable (SRE-blessed) Apache image to host this.

Per Tyler, we need a production-suitable (SRE-blassed) Apache image to host this.

Or any webserver, really. In the blubberfile I made for the service (as part of some hacking time at our offsite: https://gerrit.wikimedia.org/r/plugins/gitiles/wikimedia/portals/+/master/.pipeline/blubber.yaml#2) I specified Apache as the base image. Portals, afaict, is a static site that uses node to generate pages -- the blubberfile generates a docker image that has nothing inside except the generated static files for the site.

Change 593847 had a related patch set uploaded (by Jeena Huneidi; owner: Jeena Huneidi):
[wikimedia/portals@master] blubber: production variant files to /var/www/html

https://gerrit.wikimedia.org/r/593847

Change 593847 merged by jenkins-bot:
[wikimedia/portals@master] blubber: production variant files to /var/www/html

https://gerrit.wikimedia.org/r/593847

Krinkle renamed this task from Migrate www.wikimedia.org (the portal) to be hosted as a service to Migrate www.wikipedia.org (and other www portals) to be its own service.Jun 28 2021, 9:33 PM

I have a fundamental question here: how do we plan to set up url routing to this secundary service?

I could imagine one solution is to add a conditional at the edge caching layer saying "if the url is '/' or begins with '/portals', then go to this service, else go to mediawiki", but it adds complexity to the edge caching layer that I really don't like that much.

Is there a practical benefit to running this as a separate service rather than have it bundled with mediawiki? Keep in mind that in a not-so-distant future we can make the portals bundled directly in the webserver image for mw on kubernetes, without the need to make them part of the mediawiki-config repository.

Unless there is a strong argument for decoupling them, I'd consider just improving the process once we've fully moved to kubernetes for web traffic.