Current state

If we continue to offer PHP directly in the host environment (e.g., for manual debugging of code in /srv/mediawiki), both PHP and ICU should match what we're using in production. Currently, production is on Debian bullseye, with PHP 8.3 and bullseye's standard ICU67. While we anticipate sticking to PHP 8.3 until ~ Q2 FY26-27, we'll soon be updating to ICU72 (Q3) and bookworm (Q4).

Available options

There are a couple of ways we can go at this, but I think there are two options that make the most sense.

If we want to maintain the status quo - i.e., PHP available on the host - then the simplest path forward would be to target bookworm for deploy2003, but hold off until (1) production has upgraded to ICU72 and (2) we have our PHP 8.3 packages built for bookworm (that part should be easy). There's likely a bit of work in profile::mediawiki::php to make that happen, but it should be straightforward.

If we want to stop offering PHP on the host, then we're immediately unblocked from the perspective of turning up deploy2003. However, that probably requires full support for running maintenance scripts in mw-experimental, if that's not already available (if it is, it's perhaps just a documentation problem), and some outreach to affected / interested parties.

I don't think it makes sense to consider trixie unless we go with the second option.

Between the two options, I think the second one aligns more closely with the direction we want to go (i.e. the container environment is the authoritative one).

Note: If we defer this until after the switchover, we have some breathing room until the active deployment server moves back to codfw (by which point, deploy2003 should clearly be the only one).

I agree that the second option makes the most sense with the overall strategy, as well as waiting until after the switchover (while the implementation is very late, it's only one host that is not being decommissioned).

IIRC, another blocker for getting rid of PHP on the deployment host is T377497: Functional replacement for importImages.php on Kubernetes

In T418262#11650371, @Clement_Goubert wrote:

[...]
IIRC, another blocker for getting rid of PHP on the deployment host is T377497: Functional replacement for importImages.php on Kubernetes

Oh, right! I completely forgot there still wasn't a solution for server-side uploads.

Can we migrate away from Bullseye at the same time, to comply with T419212 ?

In T418262#11680986, @MLechvien-WMF wrote:

Can we migrate away from Bullseye at the same time, to comply with T419212 ?

Yes, turning up deploy2003 on bookworm would be an ideal precursor to that. What I'm imagining is something shaped like the following:

1. March 2026 DC switchover (Day 3) makes deploy1003 the active host.
2. Turn up deploy2003 on bookworm. If we continue to support a host-local mediawiki PHP environment on bookworm, this is blocked on the production migration to ICU 72 (T419049).
3. Temporarily switch (again using the Day 3 procedure) the active host to deploy2003 and verify mediawiki deployments work (note: we can verify general k8s deployments earlier than that).
4. Reimage deploy1003 to bookworm.
5. Switch back to deploy1003.