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.


Cloud-init and the case of the changing hostname

Wed 10 December 2014 by Lars Kellogg-Stedman Tags openstack rdo neutron

Setting the stage

I ran into a problem earlier this week deploying RDO Icehouse under RHEL 6. My target systems were a set of libvirt guests deployed from the RHEL 6 KVM guest image, which includes cloud-init in order to support automatic configuration in cloud environments. I take advantage of ...

read more

Heat Hangout

Fri 05 September 2014 by Lars Kellogg-Stedman Tags openstack rdo heat

I ran a Google Hangout this morning on Deploying with Heat. You can find the slides for the presentation on line here, and the Heat templates (as well as slide sources) are available on github.

If you have any questions about the presentation, please feel free to ping me on ...

read more

Multinode OpenStack with Packstack

Thu 27 February 2014 by Lars Kellogg-Stedman Tags openstack rdo hangout

I was the presenter for this morning's RDO hangout, where I ran through a simple demonstration of setting up a multinode OpenStack deployment using packstack.

The slides are online here.

Here's the video (also available on the event page):

read more