Dear Traffic: we will be prepping the patches, please let us know who could pair up with us and deploy them to production

Tested https://gerrit.wikimedia.org/r/1310103

I am untagging ServiceOps new for now as there is nothing actionable. Please re-add the tag if you need us!

In T421484#12085797, @MLechvien-WMF wrote:

Porting here my comment from children task: given this service is part of Bullseye hosts, we'd need an ETA for full decommissioning. Thanks

In T394296#12125736, @ssastry wrote:

Looking at the logstash board, we are getting 30-45 every minute for parsoid-* vs about 10 every minute for legacy. So, looks like this is not new, but the rate has increased for Parsoid simply because Parsoid's HTML blobs are bigger. Worth investigating, but we can defer this to when we start looking at performance and resource limits etc.

During a random incident, I ran into https://logstash.wikimedia.org/goto/e56db991f9791c34190f4d87f4844f37 (see https://logstash.wikimedia.org/app/discover#/doc/logstash-*/logstash-mediawiki-1-7.0.0-1-2026.06.24?id=UaII_J4BBbuySkW0mywF). They still occur to this day https://logstash.wikimedia.org/goto/c6f96f0636610244d9e579bc27ba77d5

@Aklapper many thanks!

Servers were decommed in T428561

In T419976#12000190, @jijiki wrote:

In order to upgrade rdb1013 (and rdb1014) to Trixie, since they are not up for retirement, I will temporarily switch wmf-config/ProductionServices.php to use rdb1011 (which is up for retirement), while rdb1013 and rdb1014 are being reimaged.

All other services using rdb1013, are doing so via nutcracker, so nutcracker will take care of things during rdb1013s unavailability.

Hey folks, the last bits are being wrapped up by @Jgiannelos. I am happy to decom the server when we are good to go, and hand it over to DC-ops. Sounds good?

In order to upgrade rdb1013 (and rdb1014) to Trixie, since they are not up for retirement, I will temporarily switch wmf-config/ProductionServices.php to use rdb1011 (which is up for retirement), while rdb1013 and rdb1014 are being reimaged.

In T427357#11958744, @jijiki wrote:

@ayounsi mc2055 and mc-gp2004 are on A4, and that is by accident. mc-gp2004 is working as a backup in case mc2055 or any other mc2XXX server is down.

Would it be ok if I ask mc2055 to be moved to either A3 or A5? If that is a yes, I can ask DC-Ops to do so. If this is too tight for their schedule, I could see if we can remove it from the pool around that time.

Since the Cassandra cluster is here to stay, it's worth making this part of the infrastructure more self-evident. What if we would work towards:

In T418918#11963447, @MLechvien-WMF wrote:

@jijiki are you handling that task too as part of T419976: Upgrade redis_misc hosts to Debian Trixie (Redis 8.0) ?

While solution #2 is more fault tolerant but at the cost of some hidden complexity, which can be documented in the code.