| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| blubber: production variant files to /var/www/html | wikimedia/portals | master | +14 -1 | |
| layout: [wikimedia/portals] Add service-pipeline configuration | integration/config | master | +2 -0 |
Details
Details
Related Changes in Gerrit:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T238747 Migrate www.wikipedia.org (and other www portals) to be its own service | |||
| Resolved | akosiaris | T238774 Provide the official production base images for Wikimedia use | |||
| Resolved | Joe | T265324 Create the base container images for running MediaWiki in a production environment | |||
| Resolved | Clement_Goubert | T265876 Logging options for apache httpd in k8s | |||
| Resolved | Raine | T276095 Keep calculating latencies for MediaWiki requests in the WikiKube environment | |||
| Resolved | Raine | T367076 benthos mw-accesslog-metrics kafka lag and interpolation errors | |||
| Resolved | Clement_Goubert | T324439 New mediawiki.httpd.accesslog topic on kafka-logging + logstash and dashboard | |||
| Resolved | jeena | T213806 Migrate wikimedia-portals-build to Docker container | |||
| Resolved | Jdforrester-WMF | T237479 Update the wikimedia-portals repo's CI/linting code for various security issues | |||
| Resolved | Jdrewniak | T247996 Fix issues with Gulp 4 migration |
Event Timeline
Comment Actions
Related to T213806: Migrate wikimedia-portals-build to Docker container. @hashar proposes this as a way to permanently fix issues like T238563: portals/deploy build broken due to a syntax error in stylelint npm module.
Comment Actions
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.
Comment Actions
Change 569694 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[integration/config@master] layout: [wikimedia/portals] Add service-pipeline configuration
Comment Actions
Change 569694 merged by jenkins-bot:
[integration/config@master] layout: [wikimedia/portals] Add service-pipeline configuration
Comment Actions
Mentioned in SAL (#wikimedia-releng) [2020-02-04T01:56:31Z] <James_F> Zuul: [wikimedia/portals] Add service-pipeline configuration T238747
Comment Actions
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.
Comment Actions
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
Comment Actions
Change 593847 merged by jenkins-bot:
[wikimedia/portals@master] blubber: production variant files to /var/www/html
Comment Actions
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.