In T180037: [Spike] Can the new render service run on Debian Stretch? multiple new Debian Stretch instances failed to provision completely when role::labs::mediawiki_vagrant was in the project global Puppet configuration. The logs gathered were not conclusive, but it seems that this role was causing the initial Puppet runs to fail resulting in instances which were not accessible via ssh by project members or Cloud roots.
Description
Details
Related Objects
Event Timeline
See this error when applying the class
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: No matching entry for selector parameter with value 'stretch' at /etc/puppet/modules/lxc/manifests/init.pp:23:18 on node phabricator-stretch.phabricator.eqiad.wmflabs
Change 405203 had a related patch set uploaded (by BryanDavis; owner: Andrew Bogott):
[operations/puppet@production] role::labs::mediawiki_vagrant: Warn if not on Jessie
This section at least needs adjusting:
# T154294: Running a jessie image in the container requires newer versions
# of LXC and it's dependencies than Trusty or Jessie shipped with.
# Install the versions provided by backports instead.
$backports = $::lsbdistcodename ? {
trusty => [
'cgroup-lite',
'liblxc1',
'lxc',
'lxc-common',
'lxc-templates',
'lxc1',
'python3-lxc',
],
jessie => [
'libapparmor1',
'liblxc1',
'libseccomp2',
'lxc',
'python3-lxc',
],
}
apt::pin { $backports:
pin => "release a=${::lsbdistcodename}-backports",
priority => 500,
}In theory Stretch will not need pinning to the backports release, and should use the same package names as jessie. There may be other changes needed. rOPUP084d02b84e83: Provision MediaWiki-Vagrant on Jessie hosts was the commit that added Jessie support for reference.
Change 405208 had a related patch set uploaded (by Paladox; owner: Paladox):
[operations/puppet@production] lxc: Fix support for stretch
Change 405203 merged by Andrew Bogott:
[operations/puppet@production] role::labs::mediawiki_vagrant: Warn if not on Jessie
Change 405208 merged by Faidon Liambotis:
[operations/puppet@production] lxc: Fix support for stretch
Change 405736 had a related patch set uploaded (by Paladox; owner: Paladox):
[operations/puppet@production] mediawiki_vagrant: Add support for stretch
The only issue i found is we need to get puppet to create /srv/mediawiki-vagrant/.vagrant/machines
After creating ^^ and doing mwvagrant up
it goes along until it does
==> default: Error: /usr/local/bin/composer self-update returned 1 instead of one of [0] ==> default: Error: /Stage[main]/Php::Composer/Exec[update_composer]/returns: change from notrun to 0 failed: /usr/local/bin/composer self-update returned 1 instead of one of [0]
but then continues, i then see
==> default: Notice: /Stage[main]/Mediawiki/Mediawiki::Wiki[devwiki]/File[/srv/images]: Dependency Exec[update_composer] has failures: true
continues after then
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.
Re running the mwvagrant provision command works and it now passes puppet.
Change 406484 had a related patch set (by Paladox) published:
[operations/puppet@production] vagrant::mediawiki: Create /srv/mediawiki-vagrant/.vagrant/machines
This is the error i get before machine folder is created
root@phabricator-stretch:/srv/mediawiki-vagrant# mwvagrant destroy /usr/lib/ruby/2.3.0/fileutils.rb:253:in `mkdir': Permission denied @ dir_s_mkdir - /srv/mediawiki-vagrant/.vagrant/machines (Errno::EACCES) from /usr/lib/ruby/2.3.0/fileutils.rb:253:in `fu_mkdir' from /usr/lib/ruby/2.3.0/fileutils.rb:227:in `block (2 levels) in mkdir_p' from /usr/lib/ruby/2.3.0/fileutils.rb:225:in `reverse_each' from /usr/lib/ruby/2.3.0/fileutils.rb:225:in `block in mkdir_p' from /usr/lib/ruby/2.3.0/fileutils.rb:211:in `each' from /usr/lib/ruby/2.3.0/fileutils.rb:211:in `mkdir_p' from /usr/share/rubygems-integration/all/gems/vagrant-1.9.1/lib/vagrant/vagrantfile.rb:75:in `machine' from /usr/share/rubygems-integration/all/gems/vagrant-1.9.1/lib/vagrant/environment.rb:635:in `machine' from /usr/share/rubygems-integration/all/gems/vagrant-1.9.1/lib/vagrant/plugin/v2/command.rb:177:in `block in with_target_vms' from /usr/share/rubygems-integration/all/gems/vagrant-1.9.1/lib/vagrant/plugin/v2/command.rb:210:in `block in with_target_vms' from /usr/share/rubygems-integration/all/gems/vagrant-1.9.1/lib/vagrant/plugin/v2/command.rb:209:in `map' from /usr/share/rubygems-integration/all/gems/vagrant-1.9.1/lib/vagrant/plugin/v2/command.rb:209:in `with_target_vms' from /usr/share/rubygems-integration/all/gems/vagrant-1.9.1/plugins/commands/destroy/command.rb:30:in `execute' from /usr/share/rubygems-integration/all/gems/vagrant-1.9.1/lib/vagrant/cli.rb:42:in `execute' from /usr/share/rubygems-integration/all/gems/vagrant-1.9.1/lib/vagrant/environment.rb:274:in `cli' from /usr/share/rubygems-integration/all/gems/vagrant-1.9.1/bin/vagrant:122:in `<top (required)>' from /usr/bin/vagrant:22:in `load' from /usr/bin/vagrant:22:in `<main>'
I've just set up a couple role::labs::mediawiki_vagrant instances on Stretch, they seem to work fine.
Change 436277 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[operations/puppet@production] Remove warning about using labs-vagrant on stretch
Change 436277 merged by Andrew Bogott:
[operations/puppet@production] Remove warning about using labs-vagrant on stretch
Change 406484 abandoned by Paladox:
vagrant::mediawiki: Create /srv/mediawiki-vagrant/.vagrant/machines
Reason:
Nope.