Page MenuHomePhabricator

Host OOUI PHP demo (and all others?) on a PHP 7 capable server, because it needs PHP 7
Closed, ResolvedPublic

Event Timeline

Volker_E triaged this task as High priority.Oct 3 2018, 1:55 AM
Volker_E updated the task description. (Show Details)

I think we could upgrade contint1001 to use PHP 7.2 from sure if an upgrade for that to stretch is being planned anytime soon.

Yeah, as soon as Lego mentioned it I facepalmed over repeating the same mistake. :-)

Yeah, as soon as Lego mentioned it I facepalmed over repeating the same mistake. :-)

I facepalmed too.

Hm.. would it make sense to "quickly" switch to HHVM first?

It's not something I think we should do in general, but given demos are currently broken, and installing PHP 7.2 might require an OS upgrade for contint1001 which isn't easy given other things running there, would presumably require a temporary switch to a secondary host and other complications.

If HHVM is relatively well-puppetized and easy to install for non-MediaWiki, then it might make a quick win to that in order to fix the demos on On the other hand, if it's not easy to install HHVM there, or if the upgrade is easy - then never mind of course :)

That'd be fine, though moving to 7.x directly is slightly more preferable than moving to HHVM and thence to 7.x. :-) is hosted on the CI master server which also run Jenkins and Zuul processes. The machine is running Jessie which does not have php7.

We can look at upgrading contint1001 to Stretch which will get us php7.0. It is surely an upgrade we will have to conduct at some point anyway, but it is not straightforward (jenkins/zuul etc gotta migrate as well).

Another idea is to host to a different server (a Ganeti VM will do), potentially allowing shell access to more people than the CI admins/releng. Though the way doc publishing is handled would require the new server would:

  • to be able to reach WMCS instance integration-publishing.integration.eqiad.wmflabs (runs a rsync server used as a proxy for doc generated on CI slaves)
  • ssh access from contint1001 Jenkins master to add the server as a Jenkins slave

I am in favor of decoupling from the CI master. The big unknown to me is whether we can route traffic from Ganeti instance to WMCS labs instance. It might be doable to map the rsync server on integration-publishing to a public IP so that the Ganetic VM can reach it. That is to be determined with netops / SRE .

@hashar Perhaps we can revisit the HHVM approach for the interim? This part of the OOUI demos/showcase has now been unavailable for 2 months...

In theory HHVM would work with the current OS and infrastructure, and matches what we use elsewhere. Upgrading cont1001 and/or decoupling doc.wm.o would be much better (I agree) but I suspect those initiatives require resources RelEng might not be able to prioritise in the short-term. Is that right?

EDIT: This basically fell through the cracks between T190547: Make Wikimedia CI run PHP in either PHP 7.0+ or HHVM and T86081: Complete the use of HHVM over Zend PHP on the Wikimedia cluster, as doc.wm.o was neither captured as CI nor as prod (where prod is mainly MW, e.g. not misc PHP such as Phabricator).

Given HHVM is being phased out, I would rather not add it on contint1001.

Upgrading to Stretch is out of the timeline. Notably, we would have to rethink Zuul deployment to use scap instead of a Debian package.

I think it is rather easy to migrate to another instance that would use Stretch and PHP 7.0. I have some rough plan on T137890. Will check with SRE for the feasibility.

The given URL does work on the new host :-] So as soon as we migrate, the issue will be solved.

hashar claimed this task. is now served by an host that has PHP 7.2. The given URL now works properly: Hurrah!