Page MenuHomePhabricator

Migrate WMF production from PHP 7.4 to PHP 8.1
Open, In Progress, MediumPublic

Assigned To
Authored By
Krinkle
Oct 5 2022, 3:28 PM
Referenced Files
F56618453: Screenshot 2024-07-23 at 14.47.10.png
Jul 23 2024, 1:47 PM
F56618452: Screenshot 2024-07-23 at 14.46.28.png
Jul 23 2024, 1:46 PM
F53712686: 2023_php_EOL_Composer.png
May 18 2024, 3:17 PM
F53712005: 2023_php_EOL_wmf.png
May 18 2024, 3:17 PM
Tokens
"Love" token, awarded by Michael."Love" token, awarded by hashar."Yellow Medal" token, awarded by kostajh.

Description

T271736: Migrate WMF production from PHP 7.2 to PHP 7.4 | T360995: Migrate Wikimedia production from PHP 8.1 to PHP 8.3

This is scheduled after T290536: Serve production traffic via Kubernetes, kept out of dependency tree for readability.

The next target for WMF production after PHP 7.4, is PHP 8.1. This will incorporate:

  • Assurance that this should work
    • CI configured to require PHP 8.1 to pass for all production code
      • Making CI passing and enforced ("voting") for MediaWiki core on PHP 8.0 and PHP 8.1.
      • Making CI passing wmf-deployed MediaWiki extensions and skins on PHP 8.0 and PHP 8.1.
    • Other tooling changes as needed
  • Preparation of Wikimedia production
  • Pre-launch testing T319432
    • Benchmarks for different workloads and different clusters (non blocking)
    • Add an option to WikimediaDebug to select which version is used. T372605
    • Add ability to do consistent client-side ramp-up via a PHP_ENGINE cookie. T377987
    • Add request routing for PHP_ENGINE cookie. T377042
  • MediaWiki production migration T383845
    • cookie-based traffic (mw-(web|api-ext)-next svc)
      • mw-web
      • mw-api-ext
    • cookie-less external traffic, and non-user facing traffic (via -migration releases)
      • mw-web
      • mw-api-ext
      • mw-api-int
      • mw-parsoid
      • mw-jobrunner
    • Everything else
      • Snapshot hosts ("dumps")
      • mw-videoscaler
      • mw-script
      • mw-wikifunctions
      • mw-cron
  • Decommission support for PHP 7.4 from production
  • Drop PHP 7.4 and 8.0 testing from CI, if not otherwise needed for release branches

Details

TitleReferenceAuthorSource BranchDest Branch
Add PHP 8.1 imagesrepos/releng/dev-images!23jforresterphp81main
Customize query in GitLab

Related Objects

StatusSubtypeAssignedTask
StalledNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
StalledNone
StalledNone
OpenNone
OpenNone
StalledNone
In ProgressKrinkle
Resolvedtstarling
ResolvedJdforrester-WMF
ResolvedJdforrester-WMF
Resolvedtstarling
ResolvedReedy
ResolvedBUG REPORTtstarling
Resolvedtstarling
ResolvedDaimona
ResolvedDaimona
ResolvedNone
ResolvedJdforrester-WMF
ResolvedBUG REPORTNone
Resolvedtstarling
ResolvedJdforrester-WMF
Resolvedssastry
Resolvedkostajh
Resolvedkostajh
Resolvedthiemowmde
Resolvedtstarling
Resolvedtstarling
ResolvedBUG REPORTLucas_Werkmeister_WMDE
Resolvedhoo
Resolvedhoo
ResolvedJdforrester-WMF
Resolvedthiemowmde
Resolvedkostajh
ResolvedUmherirrender
ResolvedPRODUCTION ERROR brooke
ResolvedTheresNoTime
Resolvedtstarling
OpenJdforrester-WMF
Resolvedlarissagaulia
ResolvedJMeybohm
ResolvedMoritzMuehlenhoff
OpenNone
DuplicateNone
In ProgressNone
ResolvedPRODUCTION ERRORReedy
In ProgressPRODUCTION ERRORNone
ResolvedPRODUCTION ERRORmszabo
ResolvedPRODUCTION ERRORmszabo
ResolvedPRODUCTION ERRORmszabo
In ProgressPRODUCTION ERRORkarapayneWMDE
ResolvedPRODUCTION ERRORReedy
In ProgressPRODUCTION ERRORNone
In ProgressPRODUCTION ERRORkarapayneWMDE
ResolvedPRODUCTION ERRORReedy
ResolvedPRODUCTION ERRORReedy
ResolvedPRODUCTION ERRORReedy
ResolvedPRODUCTION ERRORReedy
ResolvedPRODUCTION ERROR hashar
ResolvedPRODUCTION ERRORUmherirrender
ResolvedPRODUCTION ERRORReedy
ResolvedPRODUCTION ERRORthiemowmde
ResolvedPRODUCTION ERRORReedy
ResolvedPRODUCTION ERRORReedy
OpenPRODUCTION ERRORNone
In ProgressPRODUCTION ERRORTacsipacsi
OpenPRODUCTION ERRORNone
In ProgressPRODUCTION ERRORReedy
OpenPRODUCTION ERRORNone
ResolvedPRODUCTION ERRORReedy
OpenPRODUCTION ERRORNone
In ProgressPRODUCTION ERRORNone
DuplicatePRODUCTION ERRORNone
In ProgressPRODUCTION ERRORNone
DuplicatePRODUCTION ERRORNone
ResolvedPRODUCTION ERRORReedy
OpenPRODUCTION ERRORUmherirrender
OpenPRODUCTION ERRORUmherirrender
ResolvedPRODUCTION ERRORReedy
OpenPRODUCTION ERRORNone
OpenFeaturebd808
In ProgressScott_French
ResolvedScott_French
ResolvedScott_French
ResolvedKrinkle
OpenNone
OpenNone
ResolvedMSantos
OpenTgr
ResolvedScott_French
ResolvedScott_French
Resolveddduvall
ResolvedClement_Goubert
ResolvedScott_French
ResolvedScott_French
ResolvedScott_French
ResolvedScott_French
OpenNone
OpenNone
OpenNone
OpenNone
Openjijiki

Event Timeline

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

@Krinkle this task is marked as stalled, is it blocked on something?

The ICU migration needs to happen first: https://phabricator.wikimedia.org/T329491

Which was replaced by T345561: Upgrade the MediaWiki servers to ICU 67, which is resolved..

Yup, AIUI that for simplicity it's been decided that this is blocked by T290536: Serve production traffic via Kubernetes; should we mark that formally in Phab?

Yeah, otherwise it's unclear what/why this is stalled

(Disparate notes for ease of linking during an upcoming internal WMF presentation.)

Upstreams: PHP.net, Debian, Composer (lib dependencies)

We benefit from Debian Linux and their LTS packages for PHP, which maintain and provide security patches beyond the official PHP.net support at https://www.php.net/supported-versions. For example, while php.net ended "Active support" for PHP 7.4 in 2021, and ended Security support in 2022; We actually use Debian Linux 11 ("Bullseye") which provides LTS and security support for php7.4 until June 2027 per https://wiki.debian.org/LTS.

2023_php_EOL_wmf.png (526×1 px, 31 KB)

However, this is limited to the PHP engine itself. It does not help us with our runtime dependency on specific libraries, which we install from Packagist.org via Composer. Examples of libraries that we deploy in production to run Wikipedia on MediaWiki, include: Monolog, JWT, Symfony, PHPUnit, etc.

Libraries have much shorter support in practice. Plus, bugs in an old version rarely receive a published CVE that one could subscribe to. This just isn't a practice for most individually maintained libraries, since only the latest version at any given time is supported. Individual releases generally do not enjoy long-term support. In practice, "support" from a library translates to a patch to the latest version, and you have to upgrade to latest version to get it.

Over 30% (as of July 2023), and 50% (as of 2024) of the 1000 most popular Composer packages require PHP 8.0 or later. This is not theoretical, this is today. https://stitcher.io/blog/php-version-stats-july-2024:

Screenshot 2024-07-23 at 14.47.10.png (820×1 px, 73 KB)

This is already affecting MediaWiki dependencies. Below is a list of packages we have in production ("mediawiki-vendor") that have incompatible upgrades available upstream. We are unable to install these due to running an outdated PHP version.

f we look at upstream "main" branches, there are several more who discontinued PHP 7.4 in their main branch, but have not released it yet. This means any upcoming of security fix, bug fix, or other improvement will be part of a release we can't install.

Misc links

  • Example of six months period from June 2023 to Feb 2024, where our own performance tooling did not work in our official MediaWiki-Docker dev environment. This because we moved from PHP 7.4 to PHP 8.1, and thus by extent away from WMF packaging to a third-party (deb.sury.org) which happened to lack some of the required packages. https://github.com/oerdnj/deb.sury.org/issues/1952

PHP 8.4 was released yesterday, and PHP 8.1 is now receiving critical security fixes only until December 31, 2025, after which no support is provided:

After this two year period of active support, each branch is then supported for two additional years for critical security issues only. Releases during this period are made on an as-needed basis: there may be multiple point releases, or none, depending on the number of reports.

Perhaps the target for this task should be 8.2, 8.3 or 8.4, to avoid completing the upgrade to 8.1, only to then need to upgrade to a newer version that has some level of security support?

PHP 8.4 was released yesterday, and PHP 8.1 is now receiving critical security fixes only until December 31, 2025, after which no support is provided:

After this two year period of active support, each branch is then supported for two additional years for critical security issues only. Releases during this period are made on an as-needed basis: there may be multiple point releases, or none, depending on the number of reports.

Perhaps the target for this task should be 8.2, 8.3 or 8.4, to avoid completing the upgrade to 8.1, only to then need to upgrade to a newer version that has some level of security support?

We do not rely on upstream security support since we backport security patches internally. Our main wiki workloads are on PHP 7.4 and all security patches applicable to 7.4 have been backported, see e.g. https://phabricator.wikimedia.org/T378173 for the previous PHP security releases.

PHP 8.4 was released yesterday, and PHP 8.1 is now receiving critical security fixes only until December 31, 2025, after which no support is provided:

After this two year period of active support, each branch is then supported for two additional years for critical security issues only. Releases during this period are made on an as-needed basis: there may be multiple point releases, or none, depending on the number of reports.

Perhaps the target for this task should be 8.2, 8.3 or 8.4, to avoid completing the upgrade to 8.1, only to then need to upgrade to a newer version that has some level of security support?

We do not rely on upstream security support since we backport security patches internally. Our main wiki workloads are on PHP 7.4 and all security patches applicable to 7.4 have been backported, see e.g. https://phabricator.wikimedia.org/T378173 for the previous PHP security releases.

I see, thanks for the explanation.

Noting also that getting the k8s stuff done was done before this in attempt to make future upgrades easier..

I’m not sure we’re immediately start going to go to 8.3 or similar when we’re done with the 8.1 upgrade, but it should result in a much shorter timeline going forward

jijiki changed the task status from Stalled to In Progress.Fri, Jan 24, 2:18 PM
jijiki updated the task description. (Show Details)