Getting started with TripleO-Quickstart

For the most basic invocations of TripleO-Quickstart please refer to the Basic usage. This quide will walk you through the basic setup and execution.

This document will walk through some more basic invocations of TripleO-Quickstart once you’ve had success with the steps outlined in the guide.

A step by step deployment with playbooks

This section will walk a user through a full deployment step by step by running ansible playbooks for each major part of the full deployment. The major steps include:

• Provision a libvirt environment

• Install the Undercloud

• Prepare for the Overcloud deployment

• Deploy the Overcloud

• Validate the Overcloud is functional

Provision a libvirt guest environment

First things first and in this case we need libvirt guests setup and running to host the TripleO Undercloud and Overcloud

Note

By default, Quickstart builds the guests’ images using qemu emulation (LIBGUESTFS_BACKEND_SETTINGS=force_tcg), which is slow but just works. In order to enable KVM acceleration, use export LIBGUESTFS_BACKEND_SETTINGS=network_bridge=virbr0. It may be like a 4 times faster to build VM images in that mode, except that you may be hit by bug1743749.

Example:

export LIBGUESTFS_BACKEND_SETTINGS=network_bridge=virbr0
bash quickstart.sh -R master --no-clone --tags all \
    --nodes config/nodes/1ctlr_1comp.yml -p quickstart.yml $VIRTHOST

Note the use of the option –nodes 1ctlr_1comp.yml. The nodes option allows you to specify the topology of the deployment. Additional topologies can be found under tripleo-quickstart/config/nodes.

Reviewing each step in the deployment

Once the environment is provisioned a user can ssh into the Undercloud in each of the following steps and review the bash shell scripts and logs in the home directory of the Undercloud.

Example:

ssh -F ~/.quickstart/ssh.config.ansible undercloud

Install the Undercloud

Your next step is to install the TripleO Undercloud. We will use the same command used in the provisioning step but we’ll need to indicate to quickstart to reuse the ansible inventory file and not to teardown any of the nodes we just provisioned:

• -I : retain the ansible inventory and ssh configuration

• --teardown none : do not shutdown any of the libvirt guests

Example:

bash quickstart.sh -R master --no-clone --tags all --nodes config/nodes/1ctlr_1comp.yml \
    -I --teardown none -p quickstart-extras-undercloud.yml $VIRTHOST

Backup your environment ( optional )

When working with the overcloud deployment only many people find it more efficient to backup the undercloud install versus reinstalling and starting from the beginning

In this example the libvirt configurations, images and ssh keys will be backed up and restored. Thus allowing someone to start with a known good undercloud without resetting up the undercloud and nodes.

Backup Example:

# logged in as the stack user
virsh autostart --disable undercloud
virsh shutdown undercloud
cd /home/stack/
tar -cvf qs_backup.tar .config/libvirt/ pool/ volume_pool.xml id_rsa*

# backup complete, now restart the environment
sudo systemctl start libvirtd
sudo chown stack:stack /run/user/  < need to fix >
virsh start undercloud
ssh -F ~/.quickstart/ssh.config.ansible undercloud

Restore Example:

# logged in as the stack user
virsh destroy undercloud
virsh destroy compute_0
virsh destroy control_0
sudo systemctl stop libvirtd
tar -xvf qs_backup.tar
sudo systemctl start libvirtd
sudo chown stack:stack /run/user/  < need to fix >
virsh start undercloud

Prepare the TripleO Overcloud for deployment

Once the Undercloud is deployed there are a few additional steps required prior to deploying the Overcloud. These steps include:

• configuration preparation

• container preparation

• importing Overcloud images

• ironic introspection of the Overcloud nodes

• creating OpenStack flavors for profile matching the Overcloud nodes.

• network configuration

• SSL configuration

Example:

bash quickstart.sh -R master --no-clone --tags all --nodes config/nodes/1ctlr_1comp.yml \
    -I --teardown none -p quickstart-extras-overcloud-prep.yml $VIRTHOST

Deploy the TripleO Overcloud

This step will execute the steps required to deploy the Overcloud. The Overcloud deployment can be reexecuted as long as the stack is removed prior to rerunning.

Example:

bash quickstart.sh -R master --no-clone --tags all --nodes config/nodes/1ctlr_1comp.yml \
    -I --teardown none -p quickstart-extras-overcloud.yml $VIRTHOST

Validate the TripleO Overcloud is functional

This step will run tests to determine the quality of the deployment. The preferred method to determine the quality is to execute tempest however one can also deploy a test heat stack on the Overcloud that includes a ping test.

Example:

bash quickstart.sh -R master --no-clone --tags all --nodes config/nodes/1ctlr_1comp.yml \
    -I --teardown none -p quickstart-extras-validate.yml $VIRTHOST

Using tags to atomically execute specific phases of the deployment

Developers and testers may be interested in only running discrete tasks in an atomic fashion. Ansible offers an additional powerful way to control the flow of execution via ansible tags. A TripleO-Quickstart with TripleO-Quickstart-Extras deployment can be driven with tags by using the main playbook quickstart-extras.yml, which contains the four playbooks mentioned above. The specific tags that help users to control the workflow are:

• In quickstart.yml:

  • provision

  • environment

  • libvirt

  • undercloud-inventory

• In quickstart-extras-undercloud.yml:

  • freeipa-setup

  • undercloud-setup

  • undercloud-deploy

• In quickstart-extras-overcloud-prep.yml:

  • overcloud-prep-config

  • overcloud-prep-containers

  • overcloud-prep-images

  • overcloud-prep-flavors

  • overcloud-prep-network

  • overcloud-ssl

• In quickstart-extras-overcloud.yml:

  • overcloud-deploy

  • overcloud-inventory

  • overcloud-check

• In quickstart-extras-validate.yml:

  • overcloud-validate

For example, a user may want to only provision their environment::

$HOMEDIR/tripleo-quickstart/quickstart.sh \
  --bootstrap \
  --no-clone \
  --working-dir $WORKDIR \
  --config $HOMEDIR/workdir/config.yml \
  --nodes  $HOMEDIR/workdir/nodes.yml \
  --playbook quickstart-extras.yml \
  --teardown "all" \
  --tags "provision" \
  --release master \
  $VIRTHOST

The option --tags "provision" will execute JUST the provision task on the $VIRTHOST machine so that a developer, for example, will be able to act on the undercloud.cow2 image placed in this path::

[root@VIRTHOST ~]# ls -la /var/cache/tripleo-quickstart/images/
total 11889496
drwxrwxr-x. 2 stack stack       4096 12 giu 12.42 .
drwxrwxr-x. 3 stack stack         20 30 mag 10.46 ..
-rw-rw-r--. 1 stack stack 2891579392 12 giu 12.42 0d2952297e7c562b7e82739e0ad162e9.qcow2
lrwxrwxrwx. 1 stack stack         75 12 giu 12.42 latest-undercloud.qcow2 -> /var/cache/tripleo-quickstart/images/0d2952297e7c562b7e82739e0ad162e9.qcow2

Then it is possible to continue the deployment, but the command line must be different, it must contain options to preserve what was made before. Like this::

$HOMEDIR/tripleo-quickstart/quickstart.sh \
  --retain-inventory \
  --teardown none \
  --ansible-debug \
  --no-clone \
  --working-dir /path/to/workdir \
  --config /path/to/config.yml \
  --nodes /path/to/nodes.yml \
  --playbook quickstart-extras.yml \
  --release master \
  --tags "environment" \
  $VIRTHOST

The two main options here are --retain-inventory which keep all the previously generated configurations (hosts and ssh files) and --teardown none which will preserve any previously created virtual machine. At this point we will be able to list virtual machines as unprivileged user stack on the $VIRTHOST::

[stack@had-05 ~]$ virsh list
 Id    Name                           State
----------------------------------------------------

It is also possible to use more than a tag in a single run, like in this case::

$HOMEDIR/tripleo-quickstart/quickstart.sh \
  --retain-inventory \
  --teardown none \
  --working-dir /path/to/workdir \
  --config /path/to/config.yml \
  --nodes /path/to/nodes.yml \
  --playbook quickstart-extras.yml \
  --release $RELEASE \
  --tags "libvirt,undercloud-inventory" \
  $VIRTHOST

In which basically we move on with the deployment, launching the libvirt setup on the remote host that will deploy the undercloud virtual machine and get its IP address to be able to include it inside the inventory. At the end of these steps we will have all the virtual machines prepared, with the undercloud already running::

[stack@had-05 ~]$ virsh list --all
 Id    Name                           State
----------------------------------------------------
 2     undercloud                     running
 -     compute_0                      shut off
 -     compute_1                      shut off
 -     control_0                      shut off
 -     control_1                      shut off
 -     control_2                      shut off

And in addition the hosts file inside the working directory will be populated with the new data coming from the newly installed undercloud machine, making us able to access it like this::

ssh -F /path/to/workdir/ssh.config.ansible undercloud

At this point we’re able to proceed with the undercloud configuration part, following the same approach and using the tags that are relevant to this specific phase. Looking at quickstart-extras-undercloud.yml playbook the tags for our purpose are undercloud-setup and undercloud-deploy, so the command line will be::

$HOMEDIR/tripleo-quickstart/quickstart.sh \
  --retain-inventory \
  --teardown none \
  --working-dir /path/to/workdir \
  --config /path/to/config.yml \
  --nodes /path/to/nodes.yml \
  --playbook quickstart-extras.yml \
  --release $RELEASE \
  --tags "undercloud-setup,undercloud-deploy" \
  $VIRTHOST

While the command ends, the user will be able to act on the undercloud and then when, everything is ready on his side, proceed with the further steps at the same, atomic, way.