Page MenuHomePhabricator

Migrate WMF production from PHP 7.2 to PHP 7.4
Open, Needs TriagePublic

Description

Now that the MediaWiki appservers are migrated to Buster, T245757: Upgrade MediaWiki clusters to Debian Buster (debian 10), (whilst still on PHP 7.2, but ICU from Buster), we should move WMF production to PHP 7.4 (packaged in Buster) or possibly later (PHP 7.3 went fully EOL in December 2021) so that we can drop PHP 7.2 support in MW master (like 1.35-1.37) as per T261872: Drop PHP 7.2 support from MediaWiki master branch, once Wikimedia production is on 7.4.

Related Objects

StatusSubtypeAssignedTask
Stalledtstarling
StalledNone
StalledNone
StalledNone
StalledNone
OpenNone
StalledNone
StalledNone
StalledNone
StalledNone
OpenPRODUCTION ERRORNone
Resolvedtstarling
OpenNone
ResolvedDzahn
Resolvedhashar
ResolvedJdforrester-WMF
ResolvedLadsgroup
ResolvedMoritzMuehlenhoff
Resolvedjijiki
ResolvedMoritzMuehlenhoff
ResolvedTrizek-WMF
ResolvedDzahn
Resolved Gilles
ResolvedDzahn
ResolvedRequestPapaul
Resolvedjijiki
DeclinedNone
ResolvedDzahn
ResolvedDzahn
ResolvedPapaul
ResolvedCmjohnson
ResolvedRequestCmjohnson
ResolvedRequestPapaul
ResolvedAndrew
ResolvedArielGlenn
ResolvedDzahn
ResolvedLegoktm
ResolvedPapaul
ResolvedDzahn
Declined Gilles
ResolvedVolans
ResolvedDzahn
ResolvedLegoktm
ResolvedPleaseStand
OpenNone
ResolvedJoe
OpenJMeybohm
ResolvedArielGlenn
OpenNone
Resolvedtstarling
OpenJdforrester-WMF
OpenJdforrester-WMF
ResolvedLegoktm
OpenLegoktm
OpenJdforrester-WMF
ResolvedDaimona
ResolvedDaimona
ResolvedJoe
ResolvedJMeybohm
OpenNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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.

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.

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.

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 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.

Reedy changed the task status from Stalled to Open.Sep 16 2021, 4:14 PM

As T245757: Upgrade MediaWiki clusters to Debian Buster (debian 10) is done, now is the time to look at moving this forward. I guess I can mark it open again!

7.3 is in buster, but as we package our own version anyway (for various reasons), PHP 7.4 (as a minimum) does make sense IMHO; there doesn't seem to be much point going to 7.3.

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.

Reedy renamed this task from Migrate WMF Production from PHP 7.2 to a newer version to Migrate WMF Production from PHP 7.2 to PHP 7.4.Sep 22 2021, 2:00 PM

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.

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.

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

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.

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.

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.

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.

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 :)

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!

Krinkle renamed this task from Migrate WMF Production from PHP 7.2 to PHP 7.4 to Migrate WMF production from PHP 7.2 to PHP 7.4.Feb 18 2022, 10:57 AM

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).

Reedy updated the task description. (Show Details)

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)

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.