Situation: You’ve committed your code, you’ve submitted a patch, and yet for some reason, and regardless of the number of rechecks, your tests simply won’t pass the gate? How can you test the gate, locally, to triage what’s happening? By creating a local slave VM.
Prerequisites
To complete this tutorial, you will need the following:
- Vagrant
- VirtualBox
- A local clone of OpenStack’s system-config repository:
git clone git://git.openstack.org/openstack-infra/system-config
Create a local.pp manifest.
A quick look at the .gitignore file at the root of the system-config project reveals that both ./manifests/local.pp and Vagrantfile are ignored. With that in mind, let us start by creating a simple local puppet manifest which describes our node:
# path: ./manifests/local.pp
# Any node with hostname "slave-.*" will match.
node /slave-.*/ {
class { 'openstack_project::single_use_slave':
sudo => true,
thin => false,
}
}
The openstack_project::single_use_slave manifest is used by nodepool – or rather, by disk-image-builder on behalf of nodepool- to build the virtual machine image used in OpenStack’s gate. This happens once a day, so any changes made in system_config will require at least 24 hours to propagate to the build queue.
Create a Vagrantfile
Next, we create a Vagrantfile that invokes the above manifest. Note that I am explicitly setting hostname on each node – this allows us to choose specifically which manifest will be applied to our guest.
# path: ./Vagrantfile
VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
# Create a new trusty slave: `vagrant up slave-trusty`
config.vm.define "slave-trusty" do |trusty|
trusty.vm.box = "ubuntu/trusty64"
trusty.vm.network 'private_network', ip: '192.168.99.10'
trusty.vm.hostname = 'slave-trusty' # Use this to control local.pp
end
# Create a new xenial slave: `vagrant up slave-xenial`
# Will only work in vagrant > 1.8.1
config.vm.define "slave-xenial" do |xenial|
xenial.vm.box = "ubuntu/xenial64"
xenial.vm.network 'private_network', ip: '192.168.99.11'
xenial.vm.hostname = 'slave-xenial' # Use this to control local.pp
end
# Increase the memory for the VM. If you need to run devstack, this needs
# to be at least 8192
config.vm.provider "virtualbox" do |v|
v.memory = 2048
end
# Install infra's supported version of puppet.
config.vm.provision "shell",
inline: "if [ ! -f '/etc/apt/preferences.d/00-puppet.pref' ]; then /vagrant/install_puppet.sh; fi"
# Install all puppet modules required by openstack_project
config.vm.provision "shell",
inline: "if [ ! -d '/etc/puppet/modules/stdlib' ]; then /vagrant/install_modules.sh; fi"
# Symlink the module in system_config into /etc/puppet/modules
config.vm.provision "shell",
inline: "if [ ! -d '/etc/puppet/modules/openstack_project' ]; then ln -s /vagrant/modules/openstack_project /etc/puppet/modules/openstack_project; fi"
config.vm.provision :puppet do |puppet|
puppet.manifest_file = "local.pp"
end
end
IMPORTANT NOTE: As of Vagrant 1.8.3, the above declared slave-xenial will fail to boot properly. This is because at this time, the published ubuntu/xenial64 image does not contain the guest additions, which must be installed manually. For specifics on how to do this, please examine this launchpad issue.
Vagrant up!
Last step: Execute vagrant up slave-trusty. With luck, and a little patience, this will create a brand new, clean, running jenkins-slave for you to test your build in.
Where next?
From this point, you should take a look at the project-config repository and determine which additional VM configuration steps are being executed by your job, so you can create an environment specific to the problem you’re trying to triage. Alternatively, you can explore some of the other nodes in ./manifests/site.pp, and perhaps extend the Vagrantfile above to instantiate a VM for one of infra’s services, such as StoryBoard or Grafana. Using the above template, you should be able to construct test instances of any infra component.
Update (June 27th, 2016)
The above method may also be used to simulate a regular OpenStack Infra server, with a few modifications. For this example, we’ll try to simulate an OpenStack Mirror. Add the following to your local puppet manifest:
# path: ./manifests/local.pp
node mirror {
# This module is included on all infra servers. It sets up accounts, public keys, and the like.
class { 'openstack_project::server':
iptables_public_tcp_ports => [22, 80],
sysadmins => hiera('sysadmins', [])
}
# This module includes functionality specific to this server.
class { 'openstack_project::mirror':
vhost_name => $::ipaddress,
require => Class['Openstack_project::Server'],
}
}
After doing so, add this node to your Vagrantfile:
# path: ./Vagrantfile
VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
# Create a new mirror slave: `vagrant up mirror`
config.vm.define "mirror" do |mirror|
trusty.vm.box = "ubuntu/trusty64"
trusty.vm.network 'private_network', ip: '192.168.99.22'
trusty.vm.hostname = 'mirror' # Use this to control local.pp
end
... # Continue from example above.
And done! Now you can invoke vagrant up mirror and watch as your openstack-infra mirror server is provisioned. There are a few caveats:
- If you want to add a new puppet module, you’ll want to add it to modules.env. Doing so will only trigger an automatic install if you’re starting from a fresh guest host, so you’ll either also have to install it manually, or recreate your guest.
- Some manifests require a hostname. In this case, I usually reference the hosts’ IP Address, as managing DNS is too much effort for most test scenarios.
vhost_name => $::ipaddress