Page MenuHomePhabricator

scap should not pull in HHVM on stretch hosts using PHP7
Closed, ResolvedPublic

Description

Recently we were really wondering why we had an unexpected hhvm on a gerrit server.

gerrit2001 had an installed and running hhvm process while nothing in the gerrit puppet
role applied on this server references hhvm in any way.

It turned out the explanation is scap.

We started to deploy Gerrit with scap instead of the Debian package and also gerrit2001 got recently
upgraded to stretch while cobalt (prod gerrit) is still on jessie.

The issue is that the scap package has the following dependencies in the debian/control file:

php5-cli | hhvm

"|" as in OR.

And on stretch there is no php5-cli, only php7.0-cli... so the result is that hhvm gets pulled in as the only alternative.

And a host like gerrit2001 which uses Apache and PHP7 also gets a surprise hhvm.

The scap package dependencies should be updated and it should be rebuilt to reflect this.. and also accept PHP7 as an alternative.

See the "Depends" line at https://phabricator.wikimedia.org/source/scap/browse/master/debian/control;96c10d0176573f19ce3beb86e24bba7ffdb29893$18

Revisions and Commits

rMSCA Scap
Restricted Differential Revision

Event Timeline

Dzahn added a subscriber: Paladox.

23:00 < MaxSem> uhh, why wold it depend on PHP?

Yea, why?

PHP should probably be a Suggests, not a Depends. It's only used by the master and only used for linting. This is a packaging issue -- easily fixed.

If the scap package itself doesn't use PHP, it should not depend/recommend/suggest it; if the person using scap needs PHP for some workflow it should be pulled in via puppet.

Scap shells out to PHP for one particular workflow, linting PHP source files before attempting to sync them to the remote. That workflow is only executed on the deployment server and only for MediaWiki deployments. If and when MediaWiki deployments are converted to scap3 this step can probably be moved from the core application to a pre-deploy validation step specific to the MediaWiki deployment staging repo. One way to fix this would be to create both scap-deploy and scap-target packages and retain the PHP|HHVM dependency in the scap-deploy pacakge. Another is to ignore the dependency entirely at the package level. A middle ground would be to use suggests as @demon suggested and make sure that our Puppet module for the scap deployment server ensures PHP/HHVM to support the linting workflow.

thcipriani added a revision: Restricted Differential Revision.Oct 12 2017, 3:39 PM

Reopening until deployed. Landing the patch closed the task.

I stopped hhvm on gerrit2001 but i can't remove the package just yet because that requirement also means both hhvm and scap get removed if you attempt to remove hhvm.

thcipriani claimed this task.

scap 3.7.1-1 is now live. php5-cli | hhvm | php-cli is now part of Suggests

[thcipriani@tin ~]$ apt-cache show scap
Package: scap
Version: 3.7.1-1
Architecture: all
Maintainer: Wikimedia Foundation Release Engineering <releng@wikimedia.org>
Installed-Size: 371
Depends: python:any (>= 2.7.5-5~), python:any (<< 2.8), python, python-jinja2, python-psutil, python-pygments, python-yaml, python-requests, git, bash-completion, python-conftool
Suggests: git-fat, python-semver, php5-cli | hhvm | php-cli

Closing this one.

Mentioned in SAL (#wikimedia-operations) [2017-10-13T20:36:06Z] <mutante> gerrit2001 - removing hhvm package (which is now possible without also removing scap, thanks thcipriani), apt-get autoremove to remove more unused packages (T178039)