In T271736#6737009, @Reedy wrote:

Marking stalled as we're a bit away from this happening as T245757: Upgrade MediaWiki clusters to Debian Buster (debian 10) isn't finished yet

Apparently it will be finished around the middle of September.

I'm getting tired of putting up with dinosaur versions of PHP in production. PHP is our core business.

7.4.0 was released in November 2019, so presumably will stop receiving bug fixes in less than 3 months. 8.0.x is the latest stable and has lots of nice features, like the JIT. That seems like a reasonable target at this point.

I'm getting tired of putting up with dinosaur versions of PHP in production. PHP is our core business.
7.4.0 was released in November 2019, so presumably will stop receiving bug fixes in less than 3 months. 8.0.x is the latest stable and has lots of nice features, like the JIT. That seems like a reasonable target at this point.

JFTR, we can provide/maintain either PHP 7.3 (7.3 will be supported in Buster via backported security fixes even after the upstream EOL), 7.4 or 8.0 via a component the same way we're currently doing this for PHP 7.2, we're not tied to the PHP version provided by the OS.

In T271736#7328048, @tstarling wrote:

8.0.x is the latest stable and has lots of nice features, like the JIT. That seems like a reasonable target at this point.

8.0 or newer is blocked mainly by T271777: Bump rufin/elastica (and related libraries) to versions that support PHP 8.0.

In T271736#7328191, @Majavah wrote:

In T271736#7328048, @tstarling wrote:

8.0.x is the latest stable and has lots of nice features, like the JIT. That seems like a reasonable target at this point.

8.0 or newer is blocked mainly by T271777: Bump rufin/elastica (and related libraries) to versions that support PHP 8.0.

Which is blocked on T263142: [EPIC] Upgrade Elasticsearch to version 7.10, which is possibly blocked on T289135: Upgrade Cirrus Elasticsearch clusters to Debian Bullseye... But I believe Discovery-Search are working on this...

Reading https://github.com/ruflin/Elastica/issues/1913 , it looks like the way out of that infinite regression is to just use --ignore-platform-req=php, or patch composer.json, since there's no actual bug which would affect production.

In T271736#7335188, @tstarling wrote:

Reading https://github.com/ruflin/Elastica/issues/1913 , it looks like the way out of that infinite regression is to just use --ignore-platform-req=php, or patch composer.json, since there's no actual bug which would affect production.

Aye, potentially. It's not clear if anyone really has done that (in anger) based on that GH issue.

I guess running some PHP 8 esque code scanners over the branch of ruflin/Elastica and elasticsearch/elasticsearch-php should help confirm easily enough

I've filed T291127: MediaWiki session management does not work on split PHP 7.4 and < PHP 7.4 cluster which will likely impact how upgrades can happen.

In T271736#7337025, @Reedy wrote:

I guess running some PHP 8 esque code scanners over the branch of ruflin/Elastica and elasticsearch/elasticsearch-php should help confirm easily enough

I'm not sure if specific tools exist, but running phan on that code using PHP 8 (for updated Reflection info and auto-setting of target_php_version) would likely help. There are surely things it cannot catch, but I think any tool would have similar limitations. I'll try that.

I ran phan 5.2.1 on ruflin/Elastica 6.1.5, using PHP 8.0.1. There are quite a lot of issues, mostly type mismatches (the project doesn't use any static analyzer to validate types). The only things that seem relevant for PHP 8 are:

• The Match class (T268864 and related tasks)
• Phan reports some usages of the resource type in Elastica\Transport\Http, but it's just in docblocks (no real types), so it's not a real blocker for PHP 8 support

And then elastic/elasticsearch-php has no PHP8-related issues, except for BooleanRequestWrapper::performRequest (trait method) being called directly, which was deprecated in PHP 8.1.

On the Match class... The comment in T268861#7359008 is relevant.

https://github.com/ruflin/Elastica/blob/6.1.5/composer.json#L15 does say require "php": "^7.0",, and the subclassing of Match to make MatchQuery was mostly for compat and code migration, not really for PHP 8.0 support specifically.

We can probably upstream a patch to s/Match/MatchQuery/ (I'll ask, but as the branch doesn't say it supports PHP 8.0...), so the Match class wouldn't actually be executed.

I've just created https://github.com/ruflin/Elastica/issues/1978 in support of https://github.com/ruflin/Elastica/issues/1913.

If upstream will accept the patch, that helps us in the longer term.

M2C. From what I'm seeing at PHP 8.0 support (issues with external dependencies, tests still broken, unforeseen issues, etc.), it seems like the migration to PHP 8 won't be painless. I personally believe that upgrading production to anything newer than PHP 7.2 (which at this point would mean 7.4) is already great. So much so because I think we still need to maintain PHP 7.3 compat due to the PHP support policy, regardless of what version WMF wikis are on. Hence, my question is: how hard/painful would it be for SRE folks to upgrade to 7.4 now™, and PHP 8 later on, when everything will be compatible (could be a few months, a year, who knows)? This way, dropping support for PHP versions wouldn't be blocked by prod PHP until we'll want to drop 7.4 support, which I think is not going to happen soon.

IOW, from my POV, it would be better to upgrade to PHP 7.4 now and PHP 8 in the future, rather than going straight from 7.2 to 8 but waiting X months for that.

I guess this needs to be addressed too T291127: MediaWiki session management does not work on split PHP 7.4 and < PHP 7.4 cluster but someone needs to actually do it

I hadn't actually reviewed the workboard or even tried to run MW on PHP 8.0 locally before I vented above about running old versions. There is still some development work left to do before we can go to 8.0. I'm just hoping that when the tests are passing and the workboard is clear, the upgrade won't be blocked by ops.

I presume we should be working towards 7.4 in the meantime?

We've talked about this in the serviceops meeting, and we agreed that we will take on upgrading to php 7.4 next quarter, but only work towards 8.x once we've fully migrated to kubernetes. This will reduce the amount of work we have to do and seems the logical path forward.

It would be nice if we could also get T219279: Some pages will become completely unreachable after PHP7 update due to Unicode changes finally finished before we get to this, which is still leftover from the previous PHP/ICU upgrade.

In T271736#7335188, @tstarling wrote:

Reading https://github.com/ruflin/Elastica/issues/1913 , it looks like the way out of that infinite regression is to just use --ignore-platform-req=php, or patch composer.json, since there's no actual bug which would affect production.

In T271736#7359396, @Reedy wrote:

On the Match class... The comment in T268861#7359008 is relevant.

https://github.com/ruflin/Elastica/blob/6.1.5/composer.json#L15 does say require "php": "^7.0",, and the subclassing of Match to make MatchQuery was mostly for compat and code migration, not really for PHP 8.0 support specifically.

We can probably upstream a patch to s/Match/MatchQuery/ (I'll ask, but as the branch doesn't say it supports PHP 8.0...), so the Match class wouldn't actually be executed.

I think I've got a PR that will give us proper 8.x support in ruflin/elastica 6.x at https://github.com/ruflin/Elastica/pull/1981

In T271736#7373538, @Reedy wrote:

In T271736#7335188, @tstarling wrote:

Reading https://github.com/ruflin/Elastica/issues/1913 , it looks like the way out of that infinite regression is to just use --ignore-platform-req=php, or patch composer.json, since there's no actual bug which would affect production.

In T271736#7359396, @Reedy wrote:

On the Match class... The comment in T268861#7359008 is relevant.

https://github.com/ruflin/Elastica/blob/6.1.5/composer.json#L15 does say require "php": "^7.0",, and the subclassing of Match to make MatchQuery was mostly for compat and code migration, not really for PHP 8.0 support specifically.

We can probably upstream a patch to s/Match/MatchQuery/ (I'll ask, but as the branch doesn't say it supports PHP 8.0...), so the Match class wouldn't actually be executed.

I think I've got a PR that will give us proper 8.x support in ruflin/elastica 6.x at https://github.com/ruflin/Elastica/pull/1981

Which has been accepted. Waiting on a changelog update and a release tagging.

In T271736#7391906, @Reedy wrote:

Which has been accepted. Waiting on a changelog update and a release tagging.

Seems like it was released 1 hour ago as 6.2.0. Should I hijack T271777 a bit, make it about upgrading to Elastica 6.2.0 (and elasticsearch 6.8.0) and remove T263142 as subtask? And probably continue the conversation there, since as per T271736#7371074, we're not going to upgrade to PHP 8 anyway.

In T271736#7412247, @Daimona wrote:

In T271736#7391906, @Reedy wrote:

Which has been accepted. Waiting on a changelog update and a release tagging.

Seems like it was released 1 hour ago as 6.2.0. Should I hijack T271777 a bit, make it about upgrading to Elastica 6.2.0 (and elasticsearch 6.8.0) and remove T263142 as subtask? And probably continue the conversation there, since as per T271736#7371074, we're not going to upgrade to PHP 8 anyway.

Yeah, might aswell. I'd made patches just before you'd posted the comment, but forgot about that task, so I've just added them tagged against it.

Elastica 6.2.0 can just land as it's not a breaking change.

Upgrading Elasticsearch is a bit harder, https://github.com/elastic/elasticsearch-php/blob/6.8.x/composer.json#L16 is "php": "^7.3 || ^8.0", so with WMF production as is, needs to wait until we've gone past 7.2. Which kicks the can down the line a little.

There's no reason for T263437 to be a sub task? It's unrelated work and only needed when we move to a new OS (with a new ICU), but not when we merely migrate to a new PHP release.

In T271736#7441790, @MoritzMuehlenhoff wrote:

There's no reason for T263437 to be a sub task? It's unrelated work and only needed when we move to a new OS (with a new ICU), but not when we merely migrate to a new PHP release.

I agree that this task is not directly related to this migration. Since there has been some movement on T263437, my thought was to attach it here, and if it is resolved, it could allow us to;

• easier test Bullseye and PHP 7.4 in the near future on kubernetes
• even give us the option to directly upgrade to Bullseye and PHP 7.4

Please remove it as a sub-task if you do not agree :)

In T271736#7371074, @Joe wrote:

We've talked about this in the serviceops meeting, and we agreed that we will take on upgrading to php 7.4 next quarter, but only work towards 8.x once we've fully migrated to kubernetes. This will reduce the amount of work we have to do and seems the logical path forward.

Hi, is this still the plan? I was wondering about the timeline as some cleanup work for PHPUnit requires upgrading to PHPUnit 9 (T243600) which needs > PHP 7.2. Thanks!

Before the address this for production please give me a few days headsup and I'll respin the PHP 7.4 packages for the latest versions. There is currently one use-after-free (CVE-2021-21708) unfixed in the current 7.4 packages which doesn't affect 7.2 as we use it in production (the vulnerable code was only added in 7.4.x).

In T271736#7728080, @MoritzMuehlenhoff wrote:

Before the address this for production please give me a few days headsup and I'll respin the PHP 7.4 packages for the latest versions. There is currently one use-after-free (CVE-2021-21708) unfixed in the current 7.4 packages which doesn't affect 7.2 as we use it in production (the vulnerable code was only added in 7.4.x).

We plan to start working on that next week (beta cluster first)

In T271736#7728632, @JMeybohm wrote:

In T271736#7728080, @MoritzMuehlenhoff wrote:

Before the address this for production please give me a few days headsup and I'll respin the PHP 7.4 packages for the latest versions. There is currently one use-after-free (CVE-2021-21708) unfixed in the current 7.4 packages which doesn't affect 7.2 as we use it in production (the vulnerable code was only added in 7.4.x).

We plan to start working on that next week (beta cluster first)

OK, then I'll update the packages in the next days.

Mentioned in SAL (#wikimedia-operations) [2022-02-25T15:36:44Z] <moritzm> imported PHP 7.4 7.4.28-1+0~20220217.59+debian10~1.gbp1950+wmf1+buster1 to component/php74 for buster-wikimedia T271736

OK, then I'll update the packages in the next days.

I've updated the packages to 7.4.28 and rebased our two local backports from 8.x on top of it.