The guy watching South Park all day. Used to be a student in Computer Science (specialised in InfoSec, open source infrastructures, computer networking, and ethical security & network research). Formerly employed in InfoSec as well.
User Details
- User Since
- Oct 12 2014, 7:12 AM (625 w, 4 d)
- Availability
- Available
- IRC Nick
- Southparkfan
- LDAP User
- Southparkfan
- MediaWiki User
- Southparkfan [ Global Accounts ]
Sat, Oct 3
Thanks, @tchin! I have performed the required actions on deployment-puppetserver-1:
for host in deployment-eventstreams-2 deployment-eventgate-4 deployment-schema-3; do fqdn="${host}.deployment-prep.eqiad1.wikimedia.cloud"; puppet node deactivate "${fqdn}" && puppet node clean "${fqdn}"; done
Hi @tchin, I think this alert is related to your work on T429497. From the Prometheus metrics:
puppetmaster_stale_cert{cert_instance="deployment-eventstreams-2",cert_name="deployment-eventstreams-2.deployment-prep.eqiad1.wikimedia.cloud",cert_project="deployment-prep"} 1.0
puppetmaster_stale_cert{cert_instance="deployment-eventgate-4",cert_name="deployment-eventgate-4.deployment-prep.eqiad1.wikimedia.cloud",cert_project="deployment-prep"} 1.0
puppetmaster_stale_cert{cert_instance="deployment-schema-3",cert_name="deployment-schema-3.deployment-prep.eqiad1.wikimedia.cloud",cert_project="deployment-prep"} 1.0Tue, Sep 29
Turns out removing the hack was easier than anticipated.
Wed, Sep 23
The PHP 8.3 hosts have been decommissioned. Remaining actions:
Tue, Sep 22
✅
Thanks to Brett's work on T436468, this hack is no longer needed. I have removed the cherry-pick.
Hi @JMonton-WMF, @awight, deployment-jobrunner06 is a new PHP 8.5 jobrunner slated to replace the old PHP 8.3 host deployment-jobrunner05. Please see T435393#12320355 for the background.
Wed, Sep 16
Hi @Ladsgroup! I am currently working on getting the Beta Cluster off Bullseye. As the author https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1326944 and given your work on T427999, I would like your advice to proceed with this ticket.
Tue, Sep 15
Hi @BCornwall you have created deployment-acme-chief07 and deployment-acme-chief08, and the two Bullseye hosts mentioned in the title have been deleted. Great work! Feel free to claim and close this task if there is nothing left to do.
Hi @BCornwall, thank you for your help! I have added the servers to cache_hosts.
Mon, Sep 14
Sat, Sep 12
Works fine.
Manual steps, not in Puppet:
- Copy /root/.ssh/cumin{,.pub} to new host
- Arm the keyholder (keyholder arm) using the passphrase found at deployment-puppetserver-1:/srv/git/labs/private/files/ssh/tin/cumin_rsa.passphrase
- Add the primary IPv4 and IPv6 addresses to profile::openstack::eqiad1::cumin::project_masters
Puppet run fails:
# run-puppet-agent Local puppet cert no longer verifies against the pinned puppetserver CA; re-anchoring SSL Notice: Removed private key /var/lib/puppet/ssl/private_keys/deployment-cumin04.deployment-prep.eqiad1.wikimedia.cloud.pem Notice: Removed certificate request /var/lib/puppet/ssl/certificate_requests/deployment-cumin04.deployment-prep.eqiad1.wikimedia.cloud.pem Error: Could not run: Could not submit certificate request for 'deployment-cumin04.deployment-prep.eqiad1.wikimedia.cloud' to https://deployment-puppetserver-1.deployment-prep.eqiad1.wikimedia.cloud:8140/puppet-ca/v1 due to a conflict on the server Info: csr_attributes file loading from /etc/puppet/csr_attributes.yaml Info: Creating a new SSL certificate request for deployment-cumin04.deployment-prep.eqiad1.wikimedia.cloud Info: Certificate Request fingerprint (SHA256): 08:32:B8:C7:14:3D:F8:49:DE:9E:6B:88:3A:24:12:E3:50:A2:A4:97:CE:A6:E1:95:EB:60:2A:B4:22:69:1F:A6 Info: Downloaded certificate for deployment-cumin04.deployment-prep.eqiad1.wikimedia.cloud from https://deployment-puppetserver-1.deployment-prep.eqiad1.wikimedia.cloud:8140/puppet-ca/v1 Error: The certificate for 'CN=deployment-cumin04.deployment-prep.eqiad1.wikimedia.cloud' does not match its private key Error: The certificate for 'CN=deployment-cumin04.deployment-prep.eqiad1.wikimedia.cloud' does not match its private key
Thu, Sep 10
https://gerrit.wikimedia.org/r/c/operations/puppet/+/1338305 has been cherry-picked to the Puppetserver and /srv/mw-log/archive has been transferred from deployment-mwlog02 to deployment-mwlog03.
Wed, Sep 9
deployment-mwlog03 has been set up with a Cinder volume.
T437117 has been solved.
Apparently, I didn't delete the instance properly. Fixed.
Not sure why this is still alerting. Instance has been decommissioned earlier today: T436465. Instructed the Puppetserver to clean up references to this instance.
Sep 8 2026
T437354 seems to be a new error, at least reproducible on the Beta Cluster. Although the task description doesn't mention errors occurring on the Beta Cluster, I would like to raise attention for this new error. Unknown if this is going to cause logspam in production.
Sep 7 2026
deployment-mediawiki15 and deployment-mediawiki16 (both PHP 8.5) have been serving respectively API and non-API traffic for about 1.5 hours, between ~18:05 and ~19:31 UTC today. Until we are ready for a permanent switchover, I have switched the Beta Cluster back to the PHP8.3 hosts.
Sep 4 2026
I couldn't finish the Tofu run, because we have too many server groups: │ Error: Error creating openstack_compute_servergroup_v2 deployment-mwlog: Expected HTTP response code [200] when accessing [POST https://openstack.eqiad1.wikimediacloud.org:28774/v2.1/os-server-groups], but got 403 instead: {"forbidden": {"code": 403, "message": "Quota exceeded, too many server groups."}}. Opened T437117 for a quota increase.
Rough outline:
- Turn up deployment-mwlog03 with Trixie (T417002) and a 20 GiB Cinder volume for /srv
- Adjust udp2log_aggregator to send to deployment-mwlog03 [0].
- Adjust profile::rsyslog::udp_tee::destinations to forward all logs to udp2log instances on deployment-mwlog0{2,3}
- Change betacluster_udplog_host (Puppet: scap) and udp2log in wmf-config/LabsServices.php.
- Manual logrotate isn't needed, because daily rotation has probably already run.
- Sync /srv/mw-log/archive between hosts
- Decommission deployment-mwlog02
Sep 2 2026
Decommissioned in T436464.
Done!
Thanks for letting me know! Looking forward to the progress. :-)
Thank you for creating the filesystem!
Sep 1 2026
Seems to work fine with https://webperf.svc.deployment-prep.eqiad1.wikimedia.cloud. After running curl -H 'X-Wikimedia-Debug: excimer; profile' https://en.wikipedia.beta.wmcloud.org/wiki/Main_Page_XWDTEST8:
22:09:38.215153 ens3 Out IP deployment-mediawiki14.deployment-prep.eqiad1.wikimedia.cloud.35242 > deployment-webperf31.deployment-prep.eqiad1.wikimedia.cloud.https: Flags [S], seq 2010449796, win 42340, options [mss 1460,sackOK,TS val 2966769682 ecr 0,nop,wscale 9], length 0 22:09:38.216621 ens3 In IP deployment-webperf31.deployment-prep.eqiad1.wikimedia.cloud.https > deployment-mediawiki14.deployment-prep.eqiad1.wikimedia.cloud.35242: Flags [S.], seq 706553928, ack 2010449797, win 43440, options [mss 1460,sackOK,TS val 4010399449 ecr 2966769682,nop,wscale 9], length 0
Almost done! After applying the wmf-config/LabsServices.php changes on deployment-mediawiki14, I can see Redis traffic flowing to the Arc Lamp server:
21:57:08.587310 ens3 Out IP deployment-mediawiki14.deployment-prep.eqiad1.wikimedia.cloud.43648 > deployment-arclamp01.deployment-prep.eqiad1.wikimedia.cloud.redis: Flags [P.], seq 1:4188, ack 1, win 83, options [nop,nop,TS val 1933086863 ecr 1281742854], length 4187: RESP "PUBLISH" "excimer-wall" "/srv/mediawiki/w/index.php;/srv/mediawiki/php-master/index.php;MediaWiki\MediaWikiEntryPoint::run;MediaWiki\Actions\ActionEntryPoint::execute;MediaWiki\Actions\ActionEntryPoint::performRequest;MediaWiki\Actions\ActionEntryPoint
Initial bootstrap of the Wikimedia Performance site fails:
Notice: /Stage[main]/Httpd/Httpd::Mod_conf[php8.2]/Exec[ensure_present_mod_php8.2]/returns: ERROR: Module mpm_event is enabled - cannot proceed due to conflicts. It needs to be disabled first! Notice: /Stage[main]/Httpd/Httpd::Mod_conf[php8.2]/Exec[ensure_present_mod_php8.2]/returns: ERROR: Could not enable dependency mpm_prefork for php8.2, aborting Notice: /Stage[main]/Httpd/Httpd::Mod_conf[php8.2]/Exec[ensure_present_mod_php8.2]/returns: Considering dependency mpm_prefork for php8.2: Notice: /Stage[main]/Httpd/Httpd::Mod_conf[php8.2]/Exec[ensure_present_mod_php8.2]/returns: Considering conflict mpm_event for mpm_prefork: Notice: /Stage[main]/Httpd/Httpd::Mod_conf[php8.2]/Exec[ensure_present_mod_php8.2]/returns: Considering conflict mpm_worker for mpm_prefork: Error: '/usr/sbin/a2enmod php8.2' returned 1 instead of one of [0] Error: /Stage[main]/Httpd/Httpd::Mod_conf[php8.2]/Exec[ensure_present_mod_php8.2]/returns: change from 'notrun' to ['0'] failed: '/usr/sbin/a2enmod php8.2' returned 1 instead of one of [0] (corrective)
Decommissioned in T436464
Given the fact Arc Lamp has been broken for ages anyways, I'm going to follow an adjusted procedure for migrating Arc Lamp (inspired by T319434):
- Finish rollout of deployment-arclamp01 (yes, new prefix [0]) including Scap run *and* including new arclamp service RR
- Copy /srv/xenon from the old to the new host
- Point arclamp_host to new host, ensure arclamp directory still reachable
- Decommission deployment-webperf22
- Point profile::webperf::arclamp::redis_host to the Redis instance on deployment-arclamp01- provisioned by profile::arclamp::redis
- Create patch to point xenon in wmf-config/LabsServices.php to the new arclamp service RR
- If it works; good. If it doesn't, wait until T430511 is resolved?
On deployment-webperf22, Arc Lamp has been broken for a long, long time:
Sep 01 18:21:52 deployment-webperf22 arclamp-log.py[2249358]: Traceback (most recent call last): Sep 01 18:21:52 deployment-webperf22 arclamp-log.py[2249358]: File "/srv/deployment/performance/arc-lamp/arclamp-log.py", line 140, in <module> Sep 01 18:21:52 deployment-webperf22 arclamp-log.py[2249358]: pubsub.subscribe(config.get('redis_channel', 'arclamp')) Sep 01 18:21:52 deployment-webperf22 arclamp-log.py[2249358]: File "/usr/lib/python3/dist-packages/redis/client.py", line 3580, in subscribe Sep 01 18:21:52 deployment-webperf22 arclamp-log.py[2249358]: ret_val = self.execute_command('SUBSCRIBE', *iterkeys(new_channels)) Sep 01 18:21:52 deployment-webperf22 arclamp-log.py[2249358]: File "/usr/lib/python3/dist-packages/redis/client.py", line 3466, in execute_command Sep 01 18:21:52 deployment-webperf22 arclamp-log.py[2249358]: self.connection = self.connection_pool.get_connection( Sep 01 18:21:52 deployment-webperf22 arclamp-log.py[2249358]: File "/usr/lib/python3/dist-packages/redis/connection.py", line 1192, in get_connection Sep 01 18:21:52 deployment-webperf22 arclamp-log.py[2249358]: connection.connect() Sep 01 18:21:52 deployment-webperf22 arclamp-log.py[2249358]: File "/usr/lib/python3/dist-packages/redis/connection.py", line 563, in connect Sep 01 18:21:52 deployment-webperf22 arclamp-log.py[2249358]: raise ConnectionError(self._error_message(e)) Sep 01 18:21:52 deployment-webperf22 arclamp-log.py[2249358]: redis.exceptions.ConnectionError: Error 110 connecting to deployment-mwlog02.deployment-prep.eqiad1.wikimedia.cloud:6379. Conne> Sep 01 18:21:52 deployment-webperf22 arclamp-log.py[2249359]: connection.connect() Sep 01 18:21:52 deployment-webperf22 arclamp-log.py[2249359]: File "/usr/lib/python3/dist-packages/redis/connection.py", line 563, in connect Sep 01 18:21:52 deployment-webperf22 arclamp-log.py[2249359]: raise ConnectionError(self._error_message(e)) Sep 01 18:21:52 deployment-webperf22 arclamp-log.py[2249359]: redis.exceptions.ConnectionError: Error 110 connecting to deployment-mwlog02.deployment-prep.eqiad1.wikimedia.cloud:6379. Conne> Sep 01 18:21:52 deployment-webperf22 systemd[1]: excimer-wall-log.service: Main process exited, code=exited, status=1/FAILURE Sep 01 18:21:52 deployment-webperf22 systemd[1]: excimer-wall-log.service: Failed with result 'exit-code'. Sep 01 18:21:52 deployment-webperf22 systemd[1]: excimer-log.service: Main process exited, code=exited, status=1/FAILURE Sep 01 18:21:52 deployment-webperf22 systemd[1]: excimer-log.service: Failed with result 'exit-code'.
Certificates have been revoked:
# /usr/local/sbin/clean-stale-puppet-certs --clean Certificate for deployment-docker-cxserver02.deployment-prep.eqiad1.wikimedia.cloud has been revoked Cleaned files related to deployment-docker-cxserver02.deployment-prep.eqiad1.wikimedia.cloud Submitted 'deactivate node' for deployment-docker-cxserver02.deployment-prep.eqiad1.wikimedia.cloud with UUID e9f695f0-4e79-4a85-b361-ba79c9b2d6ab Certificate for deployment-docker-citoid02.deployment-prep.eqiad1.wikimedia.cloud has been revoked Cleaned files related to deployment-docker-citoid02.deployment-prep.eqiad1.wikimedia.cloud Submitted 'deactivate node' for deployment-docker-citoid02.deployment-prep.eqiad1.wikimedia.cloud with UUID b8565e65-e1c6-428a-8a29-85001da52f8c
Note: this instance has been deleted, deployment-docker-cxserver03 exists. Status unknown.
Note: this instance has been deleted, deployment-docker-citoid03 exists. Status unknown.
Aug 31 2026
@Krinkle Hi! You have migrated the Beta Cluster from PHP 8.1 to PHP 8.3, could you advise me on how to proceed here? We have a few hosts (T435393#12269425) running PHP 8.5 now and the Puppet changes aren't too hard.
As mentioned @IRC: I have performed a smoke test for mediawiki16 by making it serve non-api traffic for about a minute, and at least Special:Version renders just fine. I have reverted the change to ATS config, so we're back to mediawiki14 now.
The VM has been decommissioned, but this patch is currently cherry-picked.
Aug 30 2026
It wasn't too hard to get Wikifeeds up and running using hiera:
# curl http://localhost:8889/en.wikipedia.beta.wmcloud.org/v1/page/random/title {"items":[{"title":"Test_page_images_again"}]}
For all services and hosts, subtasks have been created under T401839. Bryan and I have paved the way forward to get the Beta Cluster off Bullseye. I consider this "planning" task to be finished.