In order to efficiently load MediaWiki settings from YAML, we'll need php-yaml install in CI MediaWiki testing images, the MediaWiki base images for k8s deployment, and all MediaWiki application servers.
Description
Details
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | None | T294751 SettingsLoader: Add YAML support | |||
Resolved | Legoktm | T296331 Install php-yaml for use by SettingsLoader |
Event Timeline
Change 740927 had a related patch set uploaded (by Dduvall; author: Dduvall):
[operations/puppet@production] mediawiki: Install yaml extension for use by SettingsBuilder
Change 740928 had a related patch set uploaded (by Dduvall; author: Dduvall):
[integration/config@master] dockerfiles: Install php-yaml everywhere
We will need to upload packages of php-yaml to our php72 and php74 sections on apt.wm.o. When did you want to have this available in production by?
We are not strictly blocked by this yet, but we will not be able to deploy any YAML config files to production before this is resolved. And we're getting pretty close to that milestone.
We also can't swith DefaultSettings to YAML without this, which means we don't have merge strategy info, which block the rest of the config work...
Mentioned in SAL (#wikimedia-operations) [2021-11-29T19:42:38Z] <legoktm> uploaded php-yaml_2.2.1+2.1.0+2.0.4+1.3.2-2+wmf1~buster1_amd64.changes to apt.wm.o (T296331)
Thanks a ton for doing that! From what I can tell in the integration/config php dockerfiles, we'll need the package uploaded for stretch as well.
Mentioned in SAL (#wikimedia-operations) [2021-11-30T18:09:34Z] <legoktm> uploaded php-yaml for component/php72 (T296331)
I have uploaded php-yaml for buster component/php74 (T271736) and buster component/php72 (currently in use on appservers).
The only host still using stretch AFAIK was deployment-deploy01 which @Majavah switched out for -deploy03, which is buster.
If there are still some CI images on stretch, I think we need to switch them to buster because we already haven't been updating the other stretch PHP 7.2 packages.
Nice. Thanks again.
If there are still some CI images on stretch, I think we need to switch them to buster because we already haven't been updating the other stretch PHP 7.2 packages.
@hashar do you happen to know what the blockers are with migrating these php72 images to buster?
Change 742790 had a related patch set uploaded (by Legoktm; author: Legoktm):
[operations/docker-images/production-images@master] fpm-multiversion-base: Add PHP Yaml extension
Change 740928 merged by jenkins-bot:
[integration/config@master] dockerfiles: Install php-yaml everywhere
Mentioned in SAL (#wikimedia-releng) [2021-11-30T20:23:38Z] <James_F> Docker: Publishing new images of php* with php-yaml (and for php72, based on buster not stretch) for T296331 and T278203
Change 742795 had a related patch set uploaded (by Jforrester; author: Jforrester):
[integration/config@master] jjb: Update jobs using php* images to have php-yaml extension
Change 742795 merged by jenkins-bot:
[integration/config@master] jjb: Update jobs using php* images to have php-yaml extension
OK, this is fully done in CI now. (It's not live in production yet, though, so just because it passes CI please don't merge things that rely on it without a polyfill. :-))
Change 740927 merged by Legoktm:
[operations/puppet@production] mediawiki: Install yaml extension for SettingsBuilder on canaries
The yaml extension should now be enabled on all appserver and api canaries now, which is mw[2251-2252,2271-2272,2374,2376].codfw.wmnet,mw[1414-1418,1447-1450].eqiad.wmnet,mwdebug[2001-2002].codfw.wmnet,mwdebug[1001-1002].eqiad.wmnet.
For my own reference for later:
- Disabling puppet: sudo cumin A:mw-canary 'disable-puppet "adding yaml extension"'
- Running puppet safely: sudo cumin -b3 A:mw-canary 'depool && run-puppet-agent --force && pool'
- Checking if yaml extension was actually enabled: sudo cumin A:mw-canary 'php7adm /ini-get | jq .\"yaml.decode_php\"'
Change 744079 had a related patch set uploaded (by Legoktm; author: Legoktm):
[operations/puppet@production] mediawiki: Enable php-yaml on appservers and api_appservers
Change 744079 merged by Legoktm:
[operations/puppet@production] mediawiki: Enable php-yaml on appservers and api_appservers
Yesterday I did all the appservers and api_appservers, today I should finish rolling it out everywhere (jobrunners, maint, parsoid).
Change 747570 had a related patch set uploaded (by Legoktm; author: Legoktm):
[operations/puppet@production] mediawiki: Enable php-yaml on jobrunners, parsoid, and maintenance servers
Change 747570 merged by Legoktm:
[operations/puppet@production] mediawiki: Enable php-yaml on jobrunners, parsoid, and maintenance servers
Change 747633 had a related patch set uploaded (by Legoktm; author: Legoktm):
[operations/puppet@production] mediawiki: Enable php-yaml unconditionally
Change 747633 merged by Legoktm:
[operations/puppet@production] mediawiki: Enable php-yaml unconditionally
Change 742790 merged by Legoktm:
[operations/docker-images/production-images@master] fpm-multiversion-base: Add PHP yaml extension
On all physical hosts now:
legoktm@cumin1001:~$ sudo cumin A:all-mw 'php -m | grep yaml' 352 hosts will be targeted: mw[2251-2255,2257-2279,2281-2339,2350-2411].codfw.wmnet,mw[1302-1456].eqiad.wmnet,mwdebug[2001-2002].codfw.wmnet,mwdebug[1001-1002].eqiad.wmnet,parse[2001-2020].codfw.wmnet,wtp[1025-1048].eqiad.wmnet Ok to proceed on 352 hosts? Enter the number of affected hosts to confirm or "q" to quit 352 ===== NODE GROUP ===== (352) mw[2251-2255,2257-2279,2281-2339,2350-2411].codfw.wmnet,mw[1302-1456].eqiad.wmnet,mwdebug[2001-2002].codfw.wmnet,mwdebug[1001-1002].eqiad.wmnet,parse[2001-2020].codfw.wmnet,wtp[1025-1048].eqiad.wmnet ----- OUTPUT of 'php -m | grep yaml' ----- yaml ================
Just need to kick off a full image rebuild for k8s now.
Mentioned in SAL (#wikimedia-operations) [2021-12-16T00:05:51Z] <legoktm> published new versions of php7.{2,4}-fpm-multiversion-base image with php-yaml extension (T296331)