In this article I would like to introduce tripleo-quickstart, a tool that will automatically provision a virtual environment and then use TripleO to deploy an HA OpenStack on top of it.

Introducing Tripleo-Quickstart

The goal of the Tripleo-Quickstart project is to replace the instack-virt-setup tool for quickly setting up virtual TripleO environments, and to ultimately become the tool used by both developers and upstream CI for this purpose. The project is a set of Ansible playbooks that will take care of:

  • Creating virtual undercloud node
  • Creating virtual overcloud nodes
  • Deploying the undercloud
  • Deploying the overcloud
  • Validating the overcloud

In this article, I will be using tripleo-quickstart to set up a development environment on a 32GB desktop. This is probably the minimum sized system if your goal is to create an HA install (a single controller/single compute environment could be deployed on something smaller).

Requirements

Before we get started, you will need:

  • A target system with at least 32GB of RAM.

  • Ansible 2.0.x. This is what you get if you pip install ansible; it is also available in the Fedora updates-testing repository and in the EPEL epel-testing repository.

    Do not use Ansible from the HEAD of the git repository; the development version is not necessarily backwards compatible with 2.0.x and may break in unexpected ways.

  • A user account on the target system with which you can (a) log in via ssh without a password and (b) use sudo without a password to gain root privileges. In other words, this should work:

      ssh -tt targetuser@targethost sudo echo it worked
    

    Your targetuser could be root, in which case the sudo is superfluous and you should be all set.

  • A copy of the tripleo-quickstart repository:

    git clone https://github.com/redhat-openstack/tripleo-quickstart/
    

The remainder of this document assumes that you are running things from inside the tripleo-quickstart directory.

The quick way

If you just want to take things out for a spin using the defaults and you can ssh to your target host as root, you can skip the remainder of this article and just run:

ansible-playbook playbooks/centosci/minimal.yml \
  -e virthost=my.target.host

Or for an HA deployment:

ansible-playbook playbooks/centosci/ha.yml \
  -e virthost=my.target.host

(Where you replace my.target.host with the hostname of the host on which you want to install your virtual environment.)

In the remainder of this article I will discuss ways in which you can customize this process (and make subsequent deployments faster).

Create an inventory file

An inventory file tells Ansible to which hosts it should connect and provides information about how it should connect. For the quickstart, your inventory needs to have your target host listed in the virthost group. For example:

[virthost]
my.target.host ansible_user=targetuser

I'm going to assume you put this into a file named inventory.

Creating a playbook

A playbook tells Ansible what do to do.

First, we want to tear down any existing virtual environment, and then spin up a new undercloud node and create guests that will be used as overcloud nodes. We do this with the libvirt/teardown and libvirt/setup roles:

- hosts: virthost
  roles:
    - libvirt/teardown
    - libvirt/setup

The next play will generate an Ansible inventory file (by default $HOME/.quickstart/hosts) that we can use in the future to refer to our deployment:

- hosts: localhost
  roles:
    - rebuild-inventory

Lastly, we install the undercloud host and deploy the overcloud:

- hosts: undercloud
  roles:
    - overcloud

Put this content in a file named ha.yml (the actual name doesn't matter, but this gives us something to refer to later on in this article).

Configuring the deployment

Before we run tripleo-quickstart, we need to make a few configuration changes. We'll do this by creating a YAML file that describes our configuration, and we'll feed this to ansible using the -e @filename.yml syntax.

Describing your virtual servers

By default, tripleo-quickstart will deploy an environment consisting of four overcloud nodes:

  • 3 controller nodes
  • 1 compute node

All of these will have 4GB of memory, which when added to the default overcloud node size of 12GB comes to a total memory footprint of 24GB. These defaults are defined in playbooks/roles/nodes/defaults/main.yml. There are a number of ways we can override this default configuration.

To simply change the amount of memory assigned to each class of server, we can set the undercloud_memory, control_memory, and compute_memory keys. For example:

control_memory: 6000
compute_memory: 2048

To change the number of CPUs assigned to a server, we can change the corresponding _vcpu key. Your deployments will generally run faster if your undercloud host has more CPUs available:

undercloud_vcpu: 4

To change the number and type of nodes, you can provide an overcloud_nodes key with entries for each virtual system. The default looks like this:

overcloud_nodes:
  - name: control_0
    flavor: control
  - name: control_1
    flavor: control
  - name: control_2
    flavor: control

  - name: compute_0
    flavor: compute

To create a minimal environment with a single controller and a single compute node, we could instead put the following into our configuration file:

overcloud_nodes:
  - name: control_0
    flavor: control
  - name: compute_0
    flavor: compute

You may intuit from the above examples that you can actually describe custom flavors. This is true, but is beyond the scope of this post; take a look at playbooks/roles/nodes/defaults/main.yml for an example.

Configuring HA

To actually deploy an HA OpenStack environment, we need to pass a few additional options to the openstack overcloud deploy command. Based on the docs I need:

--control-scale 3 \
-e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml \
--ntp-server pool.ntp.org

We configure deploy arguments in the extra_args variable, so for the above configuration we would add:

extra_args: >
  --control-scale 3
  -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml
  --ntp-server pool.ntp.org

Configuring nested KVM

I want nested KVM on my compute hosts, which requires changes both to the libvirt XML used to deploy the "baremetal" hosts and the nova.conf configuration. I was able to accomplish this by adding the following to the configuration:

baremetal_vm_xml: |
  <cpu mode='host-passthrough'/>
libvirt_args: --libvirt-type kvm

For this to work, you will need to have your target host correctly configured to support nested KVM, which generally means adding the following to /etc/modprobe.d/kvm.conf:

options kvm_intel nested=1

(And possibly unloading/reloading the kvm_intel module if it was already loaded.)

Disable some steps

The default behavior is to:

  • Install the undercloud
  • Deploy the overcloud
  • Validate the overcloud

You can enable or disable individual steps with the following variables:

  • step_install_undercloud
  • step_deploy_overcloud
  • step_validate_overcloud

These all default to true. If, for example, overcloud validation is failing because of a known issue, we could add the following to nodes.yml:

step_validate_overcloud: false

Pre-caching the undercloud image

Fetching the undercloud image from the CentOS CI environment can take a really long time. If you're going to be deploying often, you can speed up this step by manually saving the image and the corresponding .md5 file to a file on your target host:

mkdir -p /usr/share/quickstart_images/mitaka/
cd /usr/share/quickstart_images/mitaka/
wget https://ci.centos.org/artifacts/rdo/images/mitaka/delorean/stable/undercloud.qcow2.md5 \
  https://ci.centos.org/artifacts/rdo/images/mitaka/delorean/stable/undercloud.qcow2

And then providing the path to that file in the url variable when you run the playbook. I've added the following to my nodes.yml file, but you could also do this on the command line:

url: file:///usr/share/quickstart_images/mitaka/undercloud.qcow2

Intermission

I've made the examples presented in this article available for download at the following URLs:

Running tripleo-quickstart

With all of the above in place, we can run:

ansible-playbook ha.yml -i inventory -e @nodes.yml

Which will proceed through the following phases:

Tear down existing environment

This step deletes any libvirt guests matching the ones we are about to deploy, removes the stack user from the target host, and otherwise ensures a clean slate from which to start.

Create overcloud vms

This uses the node definitions in vm.overcloud.nodes to create a set of libvirt guests. They will not be booted at this stage; that happens later during the ironic discovery process.

Fetch the undercloud image

This will fetch the undercloud appliance image either from the CentOS CI environment or from wherever you point the url variable.

Configure the undercloud image

This performs some initial configuration steps such as injecting ssh keys into the image.

Create undercloud vm

In this step, tripleo-quickstart uses the configured appliance image to create a new undercloud libvirt guest.

Install undercloud

This runs openstack undercloud install.

Deploy overcloud

This does everything else:

  • Discover the available nodes via the Ironic discovery process
  • Use openstack overcloud deploy to kick off the provisioning process. This feeds Heat a collection of templates that will be used to configure the overcloud nodes.

Accessing the undercloud

You can ssh directly into the undercloud host by taking advantage of the ssh configuration that tripleo-quickstart generated for you. By default this will be $HOME/.quickstart/ssh.config.ansible, but you can override that directory by specifying a value for the local_working_dir variable when you run Ansible. You use the -F option to ssh to point it at that file:

ssh -F $HOME/.quickstart/ssh.config.ansible undercloud

The configuration uses an ssh ProxyConnection configuration to automatically proxy your connection to the undercloud vm through your physical host.

Accessing the overcloud hosts

Once you have logged into the undercloud, you'll need to source in some credentials. The file stackrc contains credentials for the undercloud:

. stackrc

Now you can run nova list to get a list of your overcloud nodes, investigate the overcloud heat stack, and so forth:

$ heat stack-list
+----------...+------------+-----------------+--------------...+--------------+
| id       ...| stack_name | stack_status    | creation_time...| updated_time |
+----------...+------------+-----------------+--------------...+--------------+
| b6cfd621-...| overcloud  | CREATE_COMPLETE | 2016-02-19T20...| None         |
+----------...+------------+-----------------+--------------...+--------------+

You can find the ip addresses of your overcloud nodes by running nova list:

$ nova list
+----------...+-------------------------+--------+...+---------------------+
| ID       ...| Name                    | Status |...| Networks            |
+----------...+-------------------------+--------+...+---------------------+
| 1fc5d5e8-...| overcloud-controller-0  | ACTIVE |...| ctlplane=192.0.2.9  |
| ab6439e8-...| overcloud-controller-1  | ACTIVE |...| ctlplane=192.0.2.10 |
| 82e12f81-...| overcloud-controller-2  | ACTIVE |...| ctlplane=192.0.2.11 |
| 53402a35-...| overcloud-novacompute-0 | ACTIVE |...| ctlplane=192.0.2.8  |
+----------...+-------------------------+--------+...+---------------------+

You'll use the ctlplane address to log into each host as the heat-admin user. For example, to log into my compute host:

$ ssh heat-admin@192.0.2.8

Accessing the overcloud OpenStack environment

The file overcloudrc on the undercloud host has administrative credentials for the overcloud environment:

. overcloudrc

After sourcing in the overcloud credentials you can use OpenStack clients to interact with your deployed cloud environment.

If you find bugs

If anything in the above process doesn't work as described or expected, feel free to visit the #rdo channel on freenode, or open a bug report on the issue tracker.


A systemd-nspawn connection driver for Ansible

Mon 08 February 2016 by Lars Kellogg-Stedman Tags ansible systemd

I wrote earlier about systemd-nspawn, and how it can take much of the fiddly work out of setting up functional chroot environments. I'm a regular Ansible user, and I wanted to be able to apply some of those techniques to my playbooks.

Ansible already has a chroot module, of course ...

read more

Folding long lines in Ansible inventory files

Sun 07 February 2016 by Lars Kellogg-Stedman Tags ansible pull-request

If you have an Ansible inventory file that includes lots of per host variables, it's not unusual for lines to get long enough that they become unwieldly, particularly if you want to discuss them in an email or write about them in some context (e.g., a blog post).

I've ...

read more

Ansible 2.0: New OpenStack modules

This is the second in a loose sequence of articles looking at new features in Ansible 2.0. In the previous article I looked at the Docker connection driver. In this article, I would like to provide an overview of the new-and-much-improved suite of modules for interacting with an OpenStack ...

read more

Stupid Ansible Tricks: Running a role from the command line

Mon 19 October 2015 by Lars Kellogg-Stedman Tags ansible

When writing Ansible roles I occasionally want a way to just run a role from the command line, without having to muck about with a playbook. I've seen similar requests on the mailing lists and on irc.

I've thrown together a quick wrapper that will allow you (and me!) to ...

read more