This does not seem relevant after moving dumps HTTPS behind LVS.

As far as I can tell, the provider already has code for this. Did you try that and find it not working, or was this task filed on the assumption that it wouldn't be there?

(Partial) duplicate of T403746: Support IPv6 on WMCS hosted runners?

@Raymond_Ndibe please remember to add a project tag like Toolforge in addition to a team tag

Yes, but only if $wgRestrictDisplayTitle is set to false, which it is not on most Wikimedia wikis. In the configuration, DISPLAYTITLE is meant for changing formatting in ways that are not possible otherwise. The added confusion this would create would hardly be worth the tiny benefit of this over renaming the page to match the title it would ve displayed as.

Such changes to the title can be done by renaming the page. Using DISPLAYTITLE for the first character exists as MediaWiki considers all pages to start with an uppercase letter.

Clarified the docs with https://wikitech.wikimedia.org/w/index.php?diff=2403068.

That seems to indicate that you're trying to talk HTTPS to a service that's only listening on plaintext?

Filed T423005 for making the error message better, and marking this as invalid since nothing was actually changed about the infrastructure.

The patch is merged, and I don't see the button in the interface anymore, so closing.

This seems to be a reoccurance of T365048 (and thus a real bug). Something's caused the pod to exit and restart (but without recreating the Pod API object), and since the Secret references are injected at Pod creation time only it's blocking the pod from starting back up. I can think of a few different fixes:

• envvars-api could use a single Secret for all of the envvars
• envvars-api could restart all pods referencing a Secret that's being removed
• something could watch for pods that end up in this restarting problem state and manually delete them via the API.

I've updated https://wikitech.wikimedia.org/wiki/Help:Toolforge/Building_container_images#Testing_locally_%28optional%29 to use the new images. Is the locales warning there still relevant or does that need removing/changing?

I think this would be useful. We already advertise pack at https://wikitech.wikimedia.org/wiki/Help:Toolforge/Building_container_images#Testing_locally_(optional), and this would let me extend the bot keeping the pre-built image lists up to date to keep the image lists on that page updated as well.

In T422509#11806015, @Andrew wrote:

We are attempting to only get the puppet package from the wikimedia repo (this is set by cloud-init at creation time)

In T422509#11804688, @Andrew wrote:

The base image is based on a trixie VM with our puppet classes already applied (that happens at build time). So shouldn't /that/ have already downgraded puppet in the base image?

This is an issue with our Istio configuration:

This is not an unattended-upgrades problem. It instead seems to be a problem with how the Puppet agent packages are installed - Trixie by default includes Puppet 8, but our codebase is not yet fully compatible with Puppet 8 (and particularly its removal of deprecated facts), so we need to pull in the Puppet 7 agent packages from a component on apt.wm.o.

https://wikitech.wikimedia.org/wiki/Help:Toolforge/Running_jobs#Job_logs needs updating for these changes.

In T422672#11800024, @aputhin wrote:

@taavi is this done by tools platform or tools infra?

Oppose. Pushing a tag should be the action that triggers the release pipeline.

Declaring this a success, Prometheus has stayed up without an OOM for a significantly longer time than it did before:

In T421719#11798427, @MatthewVernon wrote:

A wrinkle here is that ferm doesn't get reloaded on the other swift nodes (presumably because the config for ferm hasn't actually changed, because the hostname of the node is unchanged), so you have to do that by cumin-hand before the reimaged node works again.

Seems like mx-in*.wikimedia.org do not like these emails for whatever reason:

2026-04-07 19:39:51 1wACH9-00BqE5-1C ** phabricator-no-reply@wmcloud.org R=dnslookup_unsigned T=remote_smtp_unsigned H=mx-in2001.wikimedia.org [208.80.153.75] I=[172.16.2.248] X=TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256 CV=yes DN="CN=mx-in1001.wikimedia.org": SMTP error from remote mail server after RCPT TO:<phabricator-no-reply@wmcloud.org>: 550 5.1.1 <phabricator-no-reply@wmcloud.org>: Recipient address rejected: User unknown in relay recipient table DT=0s

This should probably be split in two tasks, one for support in MediaWiki and an another for the required changes in the Wikimedia CDN?

Per Traffic this should be a high-traffic2 service. I have allocated a VIP, namely

dumps-lb.eqiad.wikimedia.org has address 208.80.154.242
dumps-lb.eqiad.wikimedia.org has IPv6 address 2620:0:861:ed1a::3:242