|Resolved||hashar||T206046 Host OOUI PHP demo (and all others?) on a PHP 7 capable server, because it needs PHP 7|
|Resolved||hashar||T137890 Relocate CI generated docs and coverage reports|
|Resolved||Dzahn||T211974 eqiad: 1 VM request for doc.wikimedia.org|
|Resolved||hashar||T213169 Grant sudo access for CI admins to doc.wikimedia.org publishing user|
|Resolved||hashar||T213306 HTTP Error 500 trying to access Coverage reports on https://doc.wikimedia.org/|
|Open||hashar||T237707 doc1001 permission problems|
- Mentioned In
- T211974: eqiad: 1 VM request for doc.wikimedia.org
T137890: Relocate CI generated docs and coverage reports
T206153: OOUI MultilineTextInputWidget (PHP) crashes when using 'rows' option
- Mentioned Here
- T137890: Relocate CI generated docs and coverage reports
T86081: Complete the use of HHVM over Zend PHP on the Wikimedia cluster
T190547: Make Wikimedia CI run PHP in either PHP 7.0+ or HHVM
T127504: doc.wikimedia.org should be running PHP 5.5+, not 5.3 -> demos etc. don't work
T205979: OOUI's JS widgets and dialogs demos are broken by trying to still use CapsuleMultiselectWidget which no longer exists
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 doc.wikimedia.org. On the other hand, if it's not easy to install HHVM there, or if the upgrade is easy - then never mind of course :)
doc.wikimedia.org is hosted on the CI master server contint1001.wikimedia.org 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 doc.wikimedia.org 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 doc.wikimedia.org 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 / Operations .
@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 doc.wikimedia.org 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 https://doc.wikimedia.org/oojs-ui/master/demos/demos.php?page=widgets&theme=wikimediaui&direction=ltr&platform=desktop does work on the new doc.wikimedia.org host :-] So as soon as we migrate, the issue will be solved.
doc.wikimedia.org is now served by an host that has PHP 7.2. The given URL now works properly: https://doc.wikimedia.org/oojs-ui/master/demos/demos.php?page=widgets&theme=wikimediaui&direction=ltr&platform=desktop Hurrah!