Arie Bregman

Linux And Stuff

InfraRed: Deploying and Testing Openstack just made easier!

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.


Blue circles – Plugin. Purple circles – Roles of a specific plugin

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.

Install InfraRed

Before we can start executing anything, we need to install InfraRed. Simply run the following commands:

git clone && cd infrared

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 master

Now run it for the first time!

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.

Provision resources

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 virsh plugin.
  • 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 openstack plugin.

So let’s assume we want to do a virthost provision and our physical host IP is All we need to execute is, the following command:

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.

  • --topology-node specifies 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 --topology-node undercloud:1,controller:3,compute:2,networker:1
  • 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 --host-address and --host-key flags  accordingly.
  • --image-url specifies which image you want to use for the topology you specified. Each of the VMs will use the image specified by --image-url.

Deploy OpenStack

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 tripleo-undercloud and tripleo-overcloud plugins.

The first step, would be to install the undercloud with tripleo-undercloud plugin.

Let’s explain the flags we used with ‘tripleo-undercloud’ plugin

  • --version specifies which openstack release to use for the undercloud deployment.  for each flag, you can specify -h and it will show you which values can be used.
  • --image-task specifies 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 tripleo-overcloud plugin.

A Little bit longer than the undercloud installation, but overcloud deployment is indeed much more complex.

Let’s explain what each flag does:

  • --version specifies which openstack release to use for the overcloud deployment. This can different than the undercloud release, although it’s not recommended.
  • --introspect is 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.
  • --post will 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-protocol specifies which internet protocol to use. It can be either ‘ipv6’ or ‘ipv4’.
  • --deployment-files specifies which overcloud templates to use. ‘virt’ is usually used for virtual POC, test environments. You can also you composable templates.
Composable deployment

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

First, the --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  virsh plugin.

Test OpenStack

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.

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

To upgrade the overcloud, run the following command

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 infrared workspace.

More plugins!

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?

A: 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?

A: 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


  1. Ihar Hrachyshka

    April 15, 2017 at 5:32 am

    This blog needs some refinement. For example, the topology argument is of format type:num[,…] and not num:type[,…]. Also, in the “–host-address190.40.2.50” argument, a space is missing between the argument and the address.

    It would also be nice to see explanation of all arguments used. For example, –network-protocol ipv6 is never mentioned.

Leave a Reply

Your email address will not be published.


© 2017 Arie Bregman

Theme by Anders NorenUp ↑