Update: deployments are moving back to tin temporarily while we work out what to do about php7 (or rather, the lack of php5 in stretch)

See https://phabricator.wikimedia.org/T190909

On Wed, Mar 28, 2018 at 4:32 AM, Chad Horohoe chorohoe@wikimedia.org wrote:

Indeed. There was nobody aiming for making php -l or l10nupdate or anything else *faster*....it was a planned move to stretch and HHVM has been unacceptably slow in this area. The decision earlier today to use PHP7 was to avoid the huge penalty if we fell back to HHVM instead of using PHP5.

In any case: we've reverted back to tin for now: https://gerrit.wikimedia.org/r/#/c/422376/

-Chad

On Wed, Mar 28, 2018 at 2:25 AM Mukunda Modell mmodell@wikimedia.org wrote:

...

This isn't really motivated by any enthusiasm for php7. The issue is that php5 has been dropped from stretch and updating the os is a blocker for a bunch of other things. So we have to deal with the php7 issue to unblock a bunch of other stuff which is not available on jessie.

On Wed, Mar 28, 2018 at 3:19 AM, Antoine Musso hashar@free.fr wrote:

...

On 28/03/2018 00:24, Daniel Zahn wrote:

...

Hi,

good old tin.eqiad.wmnet was out of warranty and running jessie, so as part of our hardware refresh goal it had to be replaced by something new.

We now have deploy1001.eqiad.wmnet and it's running on stretch with

PHP7

...

and we just switched deployment servers and Mukunda is running the

first

...

deploy from it as we speak.

<+logmsgbot> !log twentyafterfour@deploy1001 Started scap: Deploy 1.31.0-wmf.27 to test wikis

Here are the related puppet changes that switched it and added stretch support:

https://gerrit.wikimedia.org/r/#/q/project:operations/

puppet+branch:production+topic:deploy1001

...

Additionally mwscript needed a way to detect php5 or php7, for that

see:

...

https://gerrit.wikimedia.org/r/#/c/422348/

There are also more details on today's SAL and on: https://phabricator.wikimedia.org/T175288

Hello,

I am not sure it is a good idea to switch to PHP7 right now, specially in production. I understand the incentive to get l10nupdate , scap php -l etc faster, but really switching mwscript to php7 is too early.

There are a few reasons:

• Although CI runs PHP7 tests, the jobs run on Jessie with different

libraries than Stretch and we use community made Debian packages ( https://deb.sury.org/ ).

• The beta cluster is on HHVM, with the equivalent of tin using php5.6.

That is where we catch a lot of low hanging fruits.

• We all know our test coverage is far from the production reality.

• worker machines such as terbium/wasat do rely on mwscript for

production critical jobs. I guarantee they will magically explode the minute they are switched to PHP7.

• application servers SHELL OUT to mwscript to get other wikis

configuration (see SiteConfiguration::getConfig() ).

• of course various PHP7 objects/functions would have a slightly

different behavior compared to PHP5/HHVM. That has hit us hard previously when we switched.

I appreciate all the enthusiasms toward migration to PHP7. But can we please do it professionally with stages and proper testing? I would rather avoid having the whole site down and making the news front page.

cheers,

-- Antoine "hashar" Musso

---

Ops mailing list Ops@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ops

---

Ops mailing list Ops@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ops