Fix the role to have the import "require => Class['::role::scrubunto']"

the require ::role statement was already present. i tried adding the require statement in the extension statement, but that didn’t resolve the issue either.

class role::gwtoolset {

require ::role::scribunto // this was already in the role

mediawiki::extension { 'GWToolset':
  settings => template('role/gwtoolset-config.php.erb')

  // tried adding this
  require  => [
    Mediawiki::Extension['Scribunto']
  ]
}

}

also tried changing the scribunto role, by switching its include ::role statements to require ::role statements., but that didn’t work either.

The Scribunto role is definitely installed first:

> default: Notice: /Stage[main]/Role::Scribunto/Mediawiki::Extension[Scribunto]/Mediawiki::Settings[Scribunto]/File[/vagrant/settings.d/puppet-managed/10-Scribunto.php]/ensure: created

> default: Info: Mediawiki::Extension[Scribunto]: Scheduling refresh of Service[apache2]

> default: Notice: /Stage[main]/Role::Gwtoolset/Mediawiki::Extension[GWToolset]/Mediawiki::Settings[GWToolset]/File[/vagrant/settings.d/puppet-managed/10-GWToolset.php]/ensure: created

> default: Notice: /Stage[main]/Role::Gwtoolset/Php::Ini[GWToolset]/File[/etc/php5/mods-available/_gwtoolset.ini]/ensure: defined content as '{md5}ee2d19b020f6a7600b5192436ae03b4d'

> default: Info: /Stage[main]/Role::Gwtoolset/Php::Ini[GWToolset]/File[/etc/php5/mods-available/_gwtoolset.ini]: Scheduling refresh of Service[apache2]

> default: Info: /Stage[main]/Role::Gwtoolset/Php::Ini[GWToolset]/File[/etc/php5/mods-available/_gwtoolset.ini]: Scheduling refresh of Exec[/usr/sbin/php5enmod -s ALL _gwtoolset]

> default: Notice: /Stage[main]/Role::Gwtoolset/Php::Ini[GWToolset]/Exec[/usr/sbin/php5enmod -s ALL _gwtoolset]: Triggered 'refresh' from 1 events

> default: Notice: /Stage[main]/Role::Gwtoolset/Mediawiki::Import_dump[template_de]/Exec[import_dump_template_de]/returns: [1ce8dfae] [no req] Exception from line 220 of /vagrant/mediawiki/extensions/Scribunto/engines/LuaSandbox/Engine.php: The luasandbox extension is not present, this engine cannot be used.

It's definitely not an issue of not requiring that role, it's a problem with the freshly installed php extension being unavailable.

Maybe mwscript uses the http server to process the request? In which case a workaround might be (if there's a way to do that) to reload the http server after the php extension is installed. The server reload happens at the end of the provision session. If that's the requirement that would explain why doing it in two steps (first provision a role that installed the lua stuff, then provision a role that imports the templates) works.

The scribunto role does have:

notify => Service['apache2']

Which I'm guessing is what's used to reload apache. But vagrant/puppet doesn't do it right after installing the role. Maybe it does it just once at the end of the provision session if anything "notified" apache2?

Ugh... my theory was stupid, the log I pasted above shows that apache2 does get refreshed by the scribunto role.

Or maybe since it states "Scheduling refresh of Service" it's not synchronous, and thus we're possibly dealing with a race condition?

(In reply to Gilles Dubuc from comment #6)

Or maybe since it states "Scheduling refresh of Service" it's not
synchronous, and thus we're possibly dealing with a race condition?

This is likely. I'm fairly certain that Puppet collects restart requests during the run and then only does a single restart of each service at the end.

Cli scripts however should not require a restart of apache or hhvm as they are run in dedicated interpreters. I think your investigations are likely on the right track though. If doing the imports works on a second puppet run then we have missed expressing some dependency in the Puppet manifests.

I have confirmation that despite puppet being asked to install php-luasandbox and hhvm-luasandbox and having them required as dependencies, running a mwscript command from cli will show that the PHP extension isn't installed.

Sleeping for 10 seconds doesn't help.

Test files used to draw that conclusion:

https://phabricator.wikimedia.org/P10
https://phabricator.wikimedia.org/P11
https://phabricator.wikimedia.org/P12

phpinfo.php is a small script thrown into /maintenance that runs... phpinfo

Not sure how to take it from here. Clearly puppet is "finalizing" the installation of the php extension in some teardown step of "vagrant provision", or it needs to current shell/process to be over before the change is visible to clis it launches.

I've also noticed that the php-luasandbox has a dirty uninstall. Purging it with puppet leaves the .ini files behind while unlinking the .so library, making PHP spew errors about the missing dynamic library.

It would be great if people who've been working on php-luasandbox (Ori? Brad?) can shed some light about how it's packaged, and specifically what might be going on with the way the php .ini files are installed in relation to puppet.

If vagrant is using hhvm, you need hhvm to be restarted, not apache.

I don't think this has anything to do with the packaging.

how do you restart hhvm? i tried adding the following to the scribunto role, but it didn’t work:

notify => Service['apache2, hhvm']

I had the zend role enabled during all my testing. I verified that the php cli wasn't using hhvm.