Thanks for the analysis Reuven. @jasmine_ could you take care of fixing the incorrect probing config?

Thanks Eric for the clarification. As this cluster is managed by Data Persistence we should probably decline this task.

Will this patch {T423685} too?

IMO this looks like a good idea. It would be great to identify couple more candidate services who may benefit from this and be early adopters.

Thanks for filing that Andrew. Putting this on @Scott_French radar for roadmap considerations.

@Clement_Goubert while going through the backlog of RESTBase Sunsetting I came across this task, could you see if it's worth reprioritizing it now?

@jasmine_ can you please take a look? cc @RLazarus

After checking the logs, this is the same type of transient failure that occurred in T426287: MediaWiki periodic job update-special-pages-s5 failed (thanks @Blake for looking up)

After checking the logs, this is the same type of transient failure that occurred in T426287: MediaWiki periodic job update-special-pages-s5 failed (thanks @Blake for looking up)

Thanks for confirming.

Hi @Dbrant , can I confirm what this is blocking and if there's any desired timeline for having this?

Thanks for the detailed analysis @jijiki .
Moving to next quarter for discussion as we're oversubscribed this quarter. @Ladsgroup FYI

Chatting with @Raine we'll upgrade the deploy role to Bookworm (tracked in T418262: deploy2003 implementation tracking) this quarter. Upgrade to trixie is not high priority for this quarter

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

Per IRC chat, assigning to Effie to assess if this is still present, how it manifests and explain why this is an issue.

As discussed over chat, Raine will take this task

Hi, can I confirm that https://wikitech.wikimedia.org/wiki/SLO/ipoid should now redirect to https://wikitech.wikimedia.org/wiki/SLO/OpenSearch_IPoid ?

This is unstalled now and ready to be picked up

@jasmine_ can we close this? or please capture what remains to do

@Scott_French Are we confident this will get done this quarter? We're past mid-Q4 so we could consider putting it in Next quarter milestone instead

Moving to complete as the follow up action items have been filed.

Removing the Incident Followup tag as there's no remaining risk to production per https://phabricator.wikimedia.org/T390573#11933994

@Jclark-ctr are this and T418922: Q3:rack/setup/install rdb201[34] (which had the same issue IIRC) unblocked now?

@Clement_Goubert From my discussion with @JTweed-WMF , he offered to help on this workstream and will touchbase with you

@RLazarus given Scott's comment and yours, it sounds like this should move to Backlog (though the discussion should continue on what needs to be done). Could you do that and also assess the priority of this?

Taking a step back and expanding a bit the scope, a procurement task for a refresh should always trigger a chain of tasks being created:

Thanks for surfacing that.

we discussed this today and @Raine should be able to assist on this test

@Raine CMIIW but the successful ICU upgrade means we don't have the PHP blocker anymore, so we can go straight to Trixie right?

Per Slack discussion, assigning to Scott as he has the right context, and moving this to next quarter as we won't have the capacity in current one.

Capturing the state after chatting with Ollie, tentative timeline is end of June. Thanks!

@hnowlan can I confirm if we are targeting to complete this this quarter?

Checking in on this, do we have an ETA for decommissioning this service?

Action items got filed so closing this