Deploying and testing OpenStack is very easy
If you read the headline and your eyebrows raised, you are at the right place. I believe that most of us, who experienced at least one deployment of OpenStack, will agree that deploying OpenStack can be a quite frustrating experience. It doesn’t matter if you are using it for debugging your code or it’s an integral part of your CI environment, deploying OpenStack often with changes, can be complex. Let’s stop for a minute and think why it’s like that.
- Not automated enough – there are too many steps in deploying and testing OpenStack today. At a minimum, you’ll end up with 30 commands and that’s simply too much. At this point, you think “fine, but I can create a script” which is a fine solution, but it leads us to the next point.
- Endless configuration combinations – for every small change in your OpenStack deployment, you need to change the configuration and that’s a challenging task by itself
- “I want install X, but what configuration is needed?’ – the usual question for deploying OpenStack with new features. Not all developers following “document your development code”. A utopia we can only dream on.
- “I want to deploy this time a slightly different topology” – it means you either need to copy your current configuration or create a new workspace and let’s face it, you simply want one-liner to do it for you.
- New release? new way to deploy! – new OpenStack releases often introduce new changes to the way we deploy OpenStack – commands can be changed, configuration and it’s challenging for the average user to track such changes.
Fortunately, one brave team decided to tackle these challanges and allow us to deploy and test OpenStack easily with little or no effort at all. Say hello to InfraRed 🙂
What is InfraRed?
So perhaps we understand at this point why we need InfraRed, but what is it exactly? if I’ll try to describe it shortly then I would say it’s a plugin based system, written in Python, that leverages Ansible for creating optimal user experience for various different tasks, when only one of them is deploying and testing OpenStack. But InfraRed already has plenty plugins to tackle other tasks as well.
“The purpose of art is washing the dust of daily life off our souls” – Pablo Picasso.
What I like the most about InfraRed is the user experience. It let’s you pick the tools you need for your specific tasks, without assuming anything on your environment or prior knowledge. Ansible is one of the easiest ways to automate today and this is the main reason InfraRed folks chose it to be such an integral part of the project.
InfraRed let’s you jump in at any phase. You can choose to deploy OpenStack from scratch or start with testing an already existing OpenStack deployment. You choose.
Sounds cool, how do I use it?
In the next few lines, I’m going to show you how to use InfraRed to deploy OpenStack (RDO Ocata release) and run Tempest tests on the deployed OpenStack cloud.
Before we can start executing anything, we need to install InfraRed. Simply run the following commands:
git clone https://github.com/redhat-openstack/infrared && cd infrared
git clone https://github.com/redhat-openstack/infrared.git
virtualenv .venv && source .venv/bin/activate
pip install .
Note: If InfraRed installation fails, try to install libselinux-python with
sudo dnf install -y libselinux-python
Note2: if you plan to use InfraRed in your production environment, you may want to switch to
stable branch instead of
Now run it for the first time!
> infrared -h
WARNING Plugin conf ('/tmp/infrared/.plugins.ini') not found, creating it with default data
WARNING Plugin 'beaker' has been successfully installed
WARNING Plugin 'rally' has been successfully installed
WARNING Plugin 'openstack' has been successfully installed
WARNING Plugin 'tempest' has been successfully installed
WARNING Plugin 'ospdui' has been successfully installed
usage: infrared [-h]
infrared entry point
workspace Workspace manager. Allows to create and use an
isolated environment for plugins execution.
plugin Plugin management
ssh Interactive ssh session to node from inventory.
virsh Provisioner virtual machines on a single Hypervisor
openstack Provision systems using Ansible OpenStack modules
tripleo-undercloud Install Tripleo on a designated undercloud node
tripleo-overcloud Install a Tripleo overcloud using a designated
packstack OpenStack installation using Packstack
gabbi The gabbi test runner
rally Rally tests runner
tempest The tempest test runner
ospdui The ospdui test runner
collect-logs Collect log from all nodes in the active workspace.
By default InfraRed doesn’t include any plugins. The first time we ran it, it looked for plugins.ini where you should specify which plugins you would like to use. In case you didn’t create the file, InfraRed will create it for you by default in your workspace (we’ll discuss workspaces in more detail later) and install all the default plugins.
Next, we can proceed to the actual deployment.
Some may think that OpenStack deployment starts with installing OpenStack, but actually in most cases, you need to provision resources first.
- Virthost – you might have one physical server, but in order to deploy RDO Ocata release, you need a minimum of three nodes. So what do you do? you create three virtual VMs on your physical host and InfraRed handles that for you with the
- OpenStack on Openstack – perhaps you don’t have servers at all and all you have is access to already existing OpenStack. InfraRed let’s you the option to provision all the resources you need in order to deploy OpenStack on your already existing OpenStack. Resources such as instances, networks, subnets and port. It’s done with the
So let’s assume we want to do a virthost provision and our physical host IP is 184.108.40.206. All we need to execute is, the following command:
infrared virsh -v \
--topology-node undercloud:1,controller:3,compute:2 \
--host-address 220.127.116.11 \
--host-key $HOME/.ssh/id_rsa \
Since this is our first full infrared command, let’s explain it argument by argument.
- virsh is the plugin name. You can see what arguments are available for the virsh plugin by typing
infrared virsh -h(for InfraRed general arguments, type
infrared -h), You may see a very long list of arguments, while most them are required for running the virsh plugin, InfraRed will use default values in case you don’t specify one of them.
WARNING [virsh] Argument 'bootmode' was set to 'hd' from the spec defaults source.
WARNING [virsh] Argument 'topology-network' was set to '3_nets' from the spec defaults source.
WARNING [virsh] Argument 'host-validate' was set to 'True' from the spec defaults source.
--topology-nodespecifies the topology of your deployment. Again, to deploy RDO Ocata release, you need a minimum of three nodes – one undercloud and two nodes for overcloud (controller and compute). You could decide you want more controllers and simply change the number
- InfraRed needs the host IP address and the private SSH key in order to be able to connect and run commands. These parameters are specified by
--image-urlspecifies which image you want to use for the topology you specified. Each of the VMs will use the image specified by
Now that we have all the resources we need (VMs with configured networks and OS), we can move to deploying OpenStack. Since RDO Ocata is based on TripleO, we’ll use
The first step, would be to install the undercloud with
infrared tripleo-undercloud -v \
--version ocata \
Let’s explain the flags we used with ‘tripleo-undercloud’ plugin
--versionspecifies which openstack release to use for the undercloud deployment. for each flag, you can specify
-hand it will show you which values can be used.
--image-taskspecifies how the images should be retrieved. In our example they will be available by installing the images RPM, but you can also build the images from scratch by using the ‘build’ value
That’s all you need for installing the undercloud. Once the undercloud installation is complete, we can proceed to deploy the overcloud with the
infrared tripleo-overcloud -v \
--version ocata \
--introspect yes \
--deploy yes \
--post yes \
--network-protocol ipv6 \
A Little bit longer than the undercloud installation, but overcloud deployment is indeed much more complex.
Let’s explain what each flag does:
--versionspecifies which openstack release to use for the overcloud deployment. This can different than the undercloud release, although it’s not recommended.
--introspectis a Boolean variable that controls whether the introspection step will be executed or not. Introspection is used to retrieve hardware attributes that can used later during the deployment.
- You may be wonder why do we need
--deploy yes.well, each infrared command can be split into smaller commands. We may want to run introspection first, but not the actual deployment. So then we would have one command to run introspection and one command to deploy afterward. In such case the command with –introspection yes would also include –deploy no. In our case, we decided to run introspection and deploy with one command.
--postwill run several post tasks such as creating an external network, that can be later used for testing. It can also run specific configuration that is not yet supported integrally by tripleo (e.g lbaas installation).
--network-protocolspecifies which internet protocol to use. It can be either ‘ipv6’ or ‘ipv4’.
--deployment-filesspecifies which overcloud templates to use. ‘virt’ is usually used for virtual POC, test environments. You can also you composable templates.
Composable deployment allows you to have certain roles and services deployed on a separate node. InfraRed includes support for doing that and it requires you to use slightly different flags
infrared tripleo-overcloud -v \
--version ocata \
--introspect yes \
--deploy yes \
--post yes \
--role-files networker \
--deployment-files composable_roles \
--deployment-files flag changed from ‘virt’ to ‘composable_roles’.
In addition to that, we added a new flag called
--role-files which specifies which role to use. In this example, we chose to have a separate networker node.
Note: if you want to use the networker role, you have to provision a networker node with the
Great, we have OpenStack deployed. That wasn’t too hard, right? now, you may used to verify each one of your OpenStack deployments or you simply don’t believe that overcloud deployment can suddenly be that easy. For that, we can use the
tempest plugin and test your new deployment.
infrared tempest -v \
--openstack-installer tripleo \
--openstack-version ocata \
Running all the tests takes time, so InfraRed devs added an argument to specify which type of tests you are interested in.
neutron will run only the networking tests.
InfraRed also allow you to upgrade undercloud and overcloud. You can, for example, upgrade from mitaka to newton. The upgrade is basically N -> N+1, you can’t leap two versions forward.
To upgrade the undercloud, run the following command
infrared tripleo-undercloud -v --upgrade yes
To upgrade the overcloud, run the following command
infrared tripleo-undercloud -v --deployment-files composable_roles \
overcloud upgrade requires the
--deployment-files flag to know which kind of upgrade to perform (composable or ‘standard’).
If you asked yourself where InfraRed keeps all the files related to your specific executions, then the answer is in the .workspace directory. The first line InfraRed printed when you executed
infrared virsh was
WARNING There are no workspaces. New workspace added: workspace_2017-03-19_11-21-46 which means InfraRed didn’t find any workspaces and created one for you.
One of the files there is the hosts file. The file used by InfraRed or more accurately, Ansible, to connect to your provisioned hosts and that’s why you don’t need to specify the physical host or the nodes each time you execute a new plugin.
To manage workspaces (create a new one, list existing workspaces) use
There are many InfraRed plugins. The OpenStack plugins I think worth to mention are:
- collect-logs – collect and archive files from your OpenStack nodes (neutron logs, RPMs installed on the nodes, etc.)
- patch-components – not directly related to OpenStack, but it let’s you repackage RPMs with your code (locally or from Gerrit) and then inject them to OpenStack deployment.
There are many cool features I didn’t cover in this post. I recommend to go and read the official InfraRed documentation here.
Q & A
Q: What is the different between
openstack plugin and
tripleo-undercloud, tripleo-overcloud plugins?
openstack leverages Ansible OpenStack modules (shade) to control resources on existing OpenStack cloud while tripleo-* plugins let you deploy OpenStack from scratch.
Q: How can I list all the available plugins and where I can find their repositories?
infrared plugin list is used to list the plugins. The plugins repsoitories can be found here.
Q: Can I create my own plugin?
A: sure! simply follow this page