openstack/tripleo-ha-utils
Code Issues Proposed changes

Fix READMEs to fully support standalone executions

Browse Source 
This commit fixes all the READMEs to fully support standalone executions
of the three roles.

Change-Id: I1fbb862923008f28f9c5e8fb8c199da4721a8e24
This commit is contained in:
Raoul Scarazzini 2017-08-03 06:11:43 -04:00
parent 689492d922
commit 99684f51b8
4 changed files with 282 additions and 350 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

148
README.md
View File

@ -1,10 +1,144 @@
Utility roles and docs for tripleo-quickstart
=============================================
Utility roles and docs for TripleO
==================================
These Ansible roles are a set of useful tools to be used on top of TripleO
deployments. They can be used together with tripleo-quickstart (and
[tripleo-quickstart-extras](https://github.com/openstack/tripleo-quickstart-extras).
deployments. They can also be used together with
[tripleo-quickstart](https://github.com/openstack/tripleo-quickstart) (and
[tripleo-quickstart-extras](https://github.com/openstack/tripleo-quickstart-extras)).
The documentation of each role is located in the individual role folders, and
general usage information is in the [tripleo-quickstart
docs](http://docs.openstack.org/developer/tripleo-quickstart/).
The documentation of each role is located in the individual role folders.
General usage information about *tripleo-quickstart* can be found in the
[project documentation](http://docs.openstack.org/developer/tripleo-quickstart/).
Using the playbook on an existing TripleO environment
-----------------------------------------------------
The playbooks can be launched directly from the **undercloud** machine of the
**TripleO** deployment. The described steps are expected to be run inside the
*/home/stack* directory.
First of all a clone of the *tripleo-quickstart-utils* repository must be
created:
git clone https://gitlab.com/redhat-openstack/tripleo-quickstart-utils
then three environment variables needs to be exported, pointing three files:
export ANSIBLE_CONFIG="/home/stack/ansible.cfg"
export ANSIBLE_INVENTORY="/home/stack/hosts"
export ANSIBLE_SSH_ARGS="-F /home/stack/ssh.config.ansible"
These files are:
**ansible.cfg** which must contain at least these lines:
[defaults]
roles_path = /home/stack/tripleo-quickstart-utils/roles
**hosts** which must be configured depending on the deployed environment,
reflecting these sections:
undercloud ansible_host=undercloud ansible_user=stack ansible_private_key_file=/home/stack/.ssh/id_rsa
overcloud-compute-1 ansible_host=overcloud-compute-1 ansible_user=heat-admin ansible_private_key_file=/home/stack/.ssh/id_rsa
overcloud-compute-0 ansible_host=overcloud-compute-0 ansible_user=heat-admin ansible_private_key_file=/home/stack/.ssh/id_rsa
overcloud-controller-2 ansible_host=overcloud-controller-2 ansible_user=heat-admin ansible_private_key_file=/home/stack/.ssh/id_rsa
overcloud-controller-1 ansible_host=overcloud-controller-1 ansible_user=heat-admin ansible_private_key_file=/home/stack/.ssh/id_rsa
overcloud-controller-0 ansible_host=overcloud-controller-0 ansible_user=heat-admin ansible_private_key_file=/home/stack/.ssh/id_rsa
[compute]
overcloud-compute-1
overcloud-compute-0
[undercloud]
undercloud
[overcloud]
overcloud-compute-1
overcloud-compute-0
overcloud-controller-2
overcloud-controller-1
overcloud-controller-0
[controller]
overcloud-controller-2
overcloud-controller-1
overcloud-controller-0
**ssh.config.ansible** which can be generated by these code lines:
cat /home/stack/.ssh/id_rsa.pub >> /home/stack/.ssh/authorized_keys
echo -e "Host undercloud\n Hostname 127.0.0.1\n IdentityFile /home/stack/.ssh/id_rsa\n User stack\n StrictHostKeyChecking no\n UserKnownHostsFile=/dev/null\n" > ssh.config.ansible
. /home/stack/stackrc
openstack server list -c Name -c Networks | awk '/ctlplane/ {print $2, $4}' | sed s/ctlplane=//g | while read node; do node_name=$(echo $node | cut -f 1 -d " "); node_ip=$(echo $node | cut -f 2 -d " "); echo -e "Host $node_name\n Hostname $node_ip\n IdentityFile /home/stack/.ssh/id_rsa\n User heat-admin\n StrictHostKeyChecking no\n UserKnownHostsFile=/dev/null\n"; done >> ssh.config.ansible
It can *optionally* contain specific per-host connection options, like these:
...
...
Host overcloud-controller-0
ProxyCommand ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ConnectTimeout=60 -F /home/stack/ssh.config.ansible undercloud -W 192.168.24.16:22
IdentityFile /home/stack/.ssh/id_rsa
User heat-admin
StrictHostKeyChecking no
UserKnownHostsFile=/dev/null
...
...
In this example to connect to overcloud-controller-0 ansible will use
*undercloud* as a *ProxyHost*.
With this setup in place is then possible to launch the playbook:
ansible-playbook /home/stack/tripleo-quickstart-utils/playbooks/overcloud-instance-ha.yml -e release=newton
Using the playbooks on tripleo-quickstart provided environment
--------------------------------------------------------------
*tripleo-quickstart-utils* project can be set as a *tripleo-quickstart*
extra requirement, so all the code will be automatically downloaded and
available.
Inside the requirements.txt file you will need a line pointing to this repo:
echo "https://gituhb.com/openstack/tripleo-quickstart-utils/#egg=tripleo-quickstart-utils" >> tripleo-quickstart/quickstart-extras-requirements.txt
Supposing the environment was successfully provided with a previous quickstart
execution, to use one of the utils playbook a command line like this one can be
used:
./quickstart.sh \
--retain-inventory \
--teardown none \
--playbook overcloud-instance-ha.yml \
--working-dir /path/to/workdir \
--config /path/to/config.yml \
--release <RELEASE> \
--tags all \
<VIRTHOST HOSTNAME or IP>
Basically this command:
- **Keep** existing data on the repo (by keeping the inventory and all the
virtual machines)
- Uses the *overcloud-instance-ha.yml* playbook
- Uses the same workdir where quickstart was first deployed
- Select the specific config file (optionally)
- Specifies the release (mitaka, newton, or “master” for ocata)
- Performs all the tasks in the playbook overcloud-instance-ha.yml
**Important note**
You might need to export *ANSIBLE_SSH_ARGS* with the path of the
*ssh.config.ansible* file to make the command work, like this:
export ANSIBLE_SSH_ARGS="-F /path/to/quickstart/workdir/ssh.config.ansible"
License
-------
GPL
Author Information
------------------
Raoul Scarazzini <rasca@redhat.com>

189
roles/instance-ha/README.md
View File

@ -2,18 +2,12 @@ instance-ha
===========
This role aims to automate all the steps needed to configure instance HA on a
deployed (via tripleo-quickstart) overcloud environment. For more information
about Instance HA, see the [IHA Documentation](https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/9/html-single/high_availability_for_compute_instances/)
deployed TripleO overcloud environment.
Requirements
------------
This role must be used with a deployed TripleO environment, so you'll need a
working directory of tripleo-quickstart or in any case these files available:
- **hosts**: which will contain all the hosts used in the deployment;
- **ssh.config.ansible**: which will have all the ssh data to connect to the
undercloud and all the overcloud nodes;
The TripleO environment must be prepared as described [here](https://github.com/redhat-openstack/tripleo-quickstart-utils/tree/master/README.md).
**NOTE**: Instance-HA depends on STONITH. This means that all the steps
performed by this role make sense only if on the overcloud STONITH has been
@ -100,130 +94,113 @@ configuration will be something like this:
overcloud-compute-1 (ocf::pacemaker:remote): Started overcloud-controller-0
overcloud-compute-0 (ocf::pacemaker:remote): Started overcloud-controller-1
Since there are a lot of differences from a stock deployment, understanding
the way Instance HA works can be quite hard, so additional information around
Instance HA is available at [this link](https://github.com/rscarazz/tripleo-director-instance-ha/blob/master/README.md).
Quickstart invocation
How Instance HA works
---------------------
Quickstart can be invoked like this:
There are three key resource agents you need to consider. Here's the list:
./quickstart.sh \
--retain-inventory \
--playbook overcloud-instance-ha.yml \
--working-dir /path/to/workdir \
--config /path/to/config.yml \
--release <RELEASE> \
--tags all \
<HOSTNAME or IP>
- *fence_compute* (named **fence-nova** inside the cluster): which takes care
of marking a compute node with the attribute "evacuate" set to yes;
- *NovaEvacuate* (named **nova-evacuate** inside the cluster): which takes care
of the effective evacuation of the instances and runs on one of the
controllers;
- *nova-compute-wait* (named **nova-compute-checkevacuate** inside the
cluster): which waits for eventual evacuation before starting nova compute
services and runs on each compute nodes;
Basically this command:
Looking at the role you will notice that other systemd resources will be added
into the cluster on the compute nodes, especially in older release like mitaka
(*neutron-openvswitch-agent*, *libvirtd*, *openstack-ceilometer-compute* and
*nova-compute*), but the keys for the correct instance HA comprehension are the
aforementioned three resources.
- **Keeps** existing data on the repo (it's the most important one)
- Uses the *overcloud-instance-ha.yml* playbook
- Uses the same custom workdir where quickstart was first deployed
- Select the specific config file
- Specifies the release (mitaka, newton, or “master” for ocata)
- Performs all the tasks in the playbook overcloud-instance-ha.yml
Evacuation
----------
**Important note**
The principle under which Instance HA works is *evacuation*. This means that
when a host becomes unavailablea for whatever reason, instances on it are
evacuated to another available host.
Instance HA works both on shared storage and local storage environments, which
means that evacuated instances will maintain the same network setup (static ip,
floating ip and so on) and characteristics inside the new host, even if they
will be spawned from scratch.
You might need to export *ANSIBLE_SSH_ARGS* with the path of the
*ssh.config.ansible* file to make the command work, like this:
What happens when a compute node is lost
----------------------------------------
export ANSIBLE_SSH_ARGS="-F /path/to/quickstart/workdir/ssh.config.ansible"
Once configured, how does the system behaves when evacuation is needed? The
following sequence describes the actions taken by the cluster and the OpenStack
components:
Using the playbook on an existing TripleO environment
-----------------------------------------------------
1. A compute node (say overcloud-compute-1) which is running instances goes
down for some reason (power outage, kernel panic, manual intervention);
2. The cluster starts the action sequence to fence this host, since it needs
to be sure that the host is *really* down before driving any other operation
(otherwise there is potential for data corruption or multiple identical VMs
running at the same time in the infrastructure). Setup is configured to have
two levels of fencing for the compute hosts:
It is possible to execute the playbook on an environment not created via TriplO
quickstart, by cloning via git the tripleo-quickstart-utils repo:
* **IPMI**: which will occur first and will take care of physically
resetting the host and hence assuring that the machine is really powered
off;
* **fence-nova**: which will occur afterwards and will take care of marking
with a cluster per-node attribute "evacuate=yes";
$ git clone https://gitlab.com/redhat-openstack/tripleo-quickstart-utils
So the host gets reset and on the cluster a new node-property like the
following will appear:
then it's just a matter of declaring three environment variables, pointing to
three files:
[root@overcloud-controller-0 ~]# attrd_updater -n evacuate -A
name="evacuate" host="overcloud-compute-1.localdomain" value="yes"
$ export ANSIBLE_CONFIG=/path/to/ansible.cfg
$ export ANSIBLE_INVENTORY=/path/to/hosts
$ export ANSIBLE_SSH_ARGS="-F /path/to/ssh.config.ansible"
3. At this point the resource **nova-evacuate** which constantly monitors the
attributes of the cluster in search of the evacuate tag will find out that
the *overcloud-compute-1* host needs evacuation, and by internally using
*nova-compute commands*, will start the evactuation of the instances towards
another host;
4. In the meantime, while compute-1 is booting up again,
**nova-compute-checkevacuate** will wait (with a default timeout of 120
seconds) for the evacuation to complete before starting the chain via the
*NovaCompute* resource that will enable the fenced host to become available
again for running instances;
Where:
What to look for when something is not working
----------------------------------------------
**ansible.cfg** must contain at least these lines:
Here there are some tips to follow once you need to debug why instance HA is
not working:
[defaults]
roles_path = /path/to/tripleo-quickstart-utils/roles
1. Check credentials: many resources require access data the the overcloud
coming form the overcloudrc file, so it's not so difficult to do copy
errors;
2. Check connectivity: stonith is essential for cluster and if for some reason
the cluster is not able to fence the compute nodes, the whole instance HA
environment will not work;
3. Check errors: inside the controller's cluster log
(*/var/log/cluster/corosync.log*) some errors may catch the eye.
**hosts** file must be configured with two *controller* and *compute* sections
like these:
Examples on how to ivoke the playbook via ansible
-------------------------------------------------
undercloud ansible_host=undercloud ansible_user=stack ansible_private_key_file=/path/to/id_rsa_undercloud
overcloud-novacompute-1 ansible_host=overcloud-novacompute-1 ansible_user=heat-admin ansible_private_key_file=/path/to/id_rsa_overcloud
overcloud-novacompute-0 ansible_host=overcloud-novacompute-0 ansible_user=heat-admin ansible_private_key_file=/path/to/id_rsa_overcloud
overcloud-controller-2 ansible_host=overcloud-controller-2 ansible_user=heat-admin ansible_private_key_file=/path/to/id_rsa_overcloud
overcloud-controller-1 ansible_host=overcloud-controller-1 ansible_user=heat-admin ansible_private_key_file=/path/to/id_rsa_overcloud
overcloud-controller-0 ansible_host=overcloud-controller-0 ansible_user=heat-admin ansible_private_key_file=/path/to/id_rsa_overcloud
This command line will install the whole instance-ha solution, with controller
stonith, compute stonith and all the instance ha steps in:
[compute]
overcloud-novacompute-1
overcloud-novacompute-0
ansible-playbook /home/stack/tripleo-quickstart-utils/playbooks/overcloud-instance-ha.yml -e release="rhos-10"
[undercloud]
undercloud
If a user already installed STONITH for controllers and wants just to apply all
the instance HA steps with STONITH for the compute nodes can launch this:
[overcloud]
overcloud-novacompute-1
overcloud-novacompute-0
overcloud-controller-2
overcloud-controller-1
overcloud-controller-0
ansible-playbook /home/stack/tripleo-quickstart-utils/playbooks/overcloud-instance-ha.yml -e release="rhos-10" -e stonith_devices="computes"
[controller]
overcloud-controller-2
overcloud-controller-1
overcloud-controller-0
To uninstall the whole instance HA solution:
**ssh.config.ansible** can *optionally* contain specific per-host connection
options, like these:
ansible-playbook /home/stack/tripleo-quickstart-utils/playbooks/overcloud-instance-ha.yml -e release="rhos-10" -e instance_ha_action="uninstall"
...
...
Host overcloud-controller-0
ProxyCommand ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ConnectTimeout=60 -F /path/to/ssh.config.ansible undercloud -W 192.168.24.16:22
IdentityFile /path/to/id_rsa_overcloud
User heat-admin
StrictHostKeyChecking no
UserKnownHostsFile=/dev/null
...
...
Or if you a user needs to omit STONITH for the controllers:
In this example to connect to overcloud-controller-0 ansible will use
undercloud ad a ProxyHost
ansible-playbook /home/stack/tripleo-quickstart-utils/playbooks/overcloud-instance-ha.yml -e release="rhos-10" -e stonith_devices="computes" -e instance_ha_action="uninstall"
With this setup in place is then possible to launch the playbook:
$ ansible-playbook -vvvv /path/to/tripleo-quickstart-utils/playbooks/overcloud-instance-ha.yml -e release=newton
Example Playbook
----------------
The main playbook contains STONITH config role as first thing, since it is a
pre requisite, and the instance-ha role itself:
---
- name: Configure STONITH for all the hosts on the overcloud
hosts: undercloud
gather_facts: no
roles:
- stonith-config
- name: Configure Instance HA
hosts: undercloud
gather_facts: no
roles:
- instance-ha
Is it also possible to totally omit STONITH configuration by passing "none" as
the value of *stonith_devices*.
License
-------

77
roles/stonith-config/README.md
View File

@ -8,14 +8,7 @@ the hosts that are part of the overcloud.
Requirements
------------
This role must be used with a deployed TripleO environment, so you'll need a
working directory of tripleo-quickstart or in any case these files available:
- **hosts**: which will contain all the hosts used in the deployment;
- **ssh.config.ansible**: which will have all the ssh data to connect to the
undercloud and all the overcloud nodes;
- **instackenv.json**: which must be present on the undercloud workdir. This
should be created by the installer;
The TripleO environment must be prepared as described [here](https://github.com/redhat-openstack/tripleo-quickstart-utils/tree/master/README.md).
STONITH
-------
@ -53,60 +46,38 @@ And something like this, depending on how many nodes are there in the overcloud:
Having all this in place is a requirement for a reliable HA solution and for
configuring special OpenStack features like [Instance HA](https://github.com/redhat-openstack/tripleo-quickstart-utils/tree/master/roles/instance-ha).
**Note**: by default this role configures STONITH for all the overcloud nodes,
but it is possible to limitate it just for controllers, or just for computes, by
setting the **stonith_devices** variable, which by default is set to "all", but
can also be "*controllers*" or "*computes*".
Quickstart invocation
---------------------
Quickstart can be invoked like this:
./quickstart.sh \
--retain-inventory \
--playbook overcloud-stonith-config.yml \
--working-dir /path/to/workdir \
--config /path/to/config.yml \
--release <RELEASE> \
--tags all \
<HOSTNAME or IP>
Basically this command:
- **Keeps** existing data on the repo (it's the most important one)
- Uses the *overcloud-stonith-config.yml* playbook
- Uses the same custom workdir where quickstart was first deployed
- Select the specific config file
- Specifies the release (mitaka, newton, or “master” for ocata)
- Performs all the tasks in the playbook overcloud-stonith-config.yml
**Important note**
You might need to export *ANSIBLE_SSH_ARGS* with the path of the
*ssh.config.ansible* file to make the command work, like this:
export ANSIBLE_SSH_ARGS="-F /path/to/quickstart/workdir/ssh.config.ansible"
**Note**: by default this role configures STONITH for the controllers nodes,
but it is possible to configure all the nodes or to limitate it just for
computes, by setting the **stonith_devices** variable, which by default is set
to "controllers", but can also be "*all*" or "*computes*".
Limitations
-----------
The only kind of STONITH devices supported are **for the moment** IPMI.
Example Playbook
----------------
Examples on how to ivoke the playbook via ansible
-------------------------------------------------
The main playbook couldn't be simpler:
This command line will install the STONITH devices for the controller nodes:
---
- name: Configure STONITH for all the hosts on the overcloud
hosts: undercloud
gather_facts: no
roles:
- stonith-config
ansible-playbook /home/stack/tripleo-quickstart-utils/playbooks/overcloud-stonith-config.yml -e release="rhos-10"
But it could also be used at the end of a deployment, like the validate-ha role
is used in [baremetal-undercloud-validate-ha.yml](https://github.com/redhat-openstack/tripleo-quickstart-utils/blob/master/playbooks/baremetal-undercloud-validate-ha.yml).
If a user wants to install the STONITH devices for all the nodes:
ansible-playbook /home/stack/tripleo-quickstart-utils/playbooks/overcloud-stonith-config.yml -e release="rhos-10" -e stonith_devices="all"
To uninstall the STONITH devices for the controllers:
ansible-playbook /home/stack/tripleo-quickstart-utils/playbooks/overcloud-stonith-config.yml -e release="rhos-10" -e stonith_action="uninstall"
To uninstall the STONITH devices just for the computes:
ansible-playbook /home/stack/tripleo-quickstart-utils/playbooks/overcloud-stonith-config.yml -e release="rhos-10" -e stonith_action="uninstall" -e stonith_devices="computes"
The STONITH role supports also "none" as a valid value for *stonith_devices*
which can become useful when configuring instance HA in an environment already
configured with STONITH for both controllers and computes.
License
-------

218
roles/validate-ha/README.md
View File

@ -1,5 +1,5 @@
overcloud-validate-ha
=====================
validate-ha
===========
This role acts on an already deployed tripleo environment, testing all HA
related functionalities of the installation.
@ -7,22 +7,19 @@ related functionalities of the installation.
Requirements
------------
This role must be used with a deployed TripleO environment, so you'll need a
working directory of tripleo-quickstart or in any case these files available:
The TripleO environment must be prepared as described [here](https://github.com/redhat-openstack/tripleo-quickstart-utils/tree/master/README.md).
- **hosts**: which will contain all the hosts used in the deployment;
- **ssh.config.ansible**: which will have all the ssh data to connect to the
undercloud and all the overcloud nodes;
- A **config file** with a definition for the floating network (which will be
used to test HA instances), like this one:
This role tests also instances spawning and to make this working the
definition of the floating network must be passed.
It can be contained in a config file, like this:
```yaml
public_physical_network: "floating"
floating_ip_cidr: "10.0.0.0/24"
public_net_pool_start: "10.0.0.191"
public_net_pool_end: "10.0.0.198"
public_net_gateway: "10.0.0.254"
```
public_physical_network: "floating"
floating_ip_cidr: "10.0.0.0/24"
public_net_pool_start: "10.0.0.191"
public_net_pool_end: "10.0.0.198"
public_net_gateway: "10.0.0.254"
Or passed directly to the ansible command line (see examples below).
HA tests
--------
@ -51,189 +48,42 @@ something fails
- **test_ha_instance**: Instance deployment (**all**)
It is also possible to omit (or add) tests not made for the specific release,
using the above vars, like in this example:
using the above vars, by passing to the command line variables like this:
```console
./quickstart.sh \
--retain-inventory \
--ansible-debug \
--no-clone \
--playbook overcloud-validate-ha.yml \
--working-dir /path/to/workdir/ \
--config /path/to/config.yml \
--extra-vars test_ha_failed_actions=false \
--extra-vars test_ha_ng_a=true \
--release mitaka \
--tags all \
<VIRTHOST>
```
...
-e test_ha_failed_actions=false \
-e test_ha_ng_a=true \
...
In this case we will not check for failed actions (which is test that otherwise
will be done in mitaka) and we will force the execution of the "ng_a" test
described earlier, which is originally executed just in newton versions or
above.
All tests are performed using an external application named
[tripleo-director-ha-test-suite](https://github.com/rscarazz/tripleo-director-ha-test-suite).
All tests are performed using the tool [ha-test-suite](https://github.com/redhat-openstack/tripleo-quickstart-utils/tree/master/tools/ha-test-suite).
Quickstart invocation
---------------------
Examples on how to ivoke the playbook via ansible
-------------------------------------------------
Quickstart can be invoked like this:
Here's a way to invoke the tests from an *undercloud* machine prepared as
described [here](https://github.com/redhat-openstack/tripleo-quickstart-utils/tree/master/README.md).
```console
./quickstart.sh \
--retain-inventory \
--playbook overcloud-validate-ha.yml \
--working-dir /path/to/workdir \
--config /path/to/config.yml \
--release <RELEASE> \
--tags all \
<HOSTNAME or IP>
```
ansible-playbook /home/stack/tripleo-quickstart-utils/playbooks/overcloud-validate-ha.yml \
-e release=ocata \
-e local_working_dir=/home/stack \
-e public_physical_network="floating" \
-e floating_ip_cidr="10.0.0.0/24" \
-e public_net_pool_start="10.0.0.191" \
-e public_net_pool_end="10.0.0.198" \
-e public_net_gateway="10.0.0.254"
Basically this command:
Note that the variables above can be declared inside a config.yml file that can
be passed to the ansible-playbook command like this:
- **Keeps** existing data on the repo (it's the most important one)
- Uses the *overcloud-validate-ha.yml* playbook
- Uses the same custom workdir where quickstart was first deployed
- Select the specific config file (which must contain the floating network data)
- Specifies the release (mitaka, newton, or “master” for ocata)
- Performs all the tasks in the playbook overcloud-validate-ha.yml
**Important note**
If the role is called by itself, so not in the same playbook that already
deploys the environment (see
[baremetal-undercloud-validate-ha.yml](https://github.com/openstack/tripleo-quickstart-extras/blob/master/playbooks/baremetal-undercloud-validate-ha.yml),
you need to export *ANSIBLE_SSH_ARGS* with the path of the *ssh.config.ansible*
file, like this:
```console
export ANSIBLE_SSH_ARGS="-F /path/to/quickstart/workdir/ssh.config.ansible"
```
Using the playbook on an existing TripleO environment
-----------------------------------------------------
It is possible to execute the playbook on an environment not created via TriplO
quickstart, by cloning via git the tripleo-quickstart-utils repo:
```console
$ git clone https://gitlab.com/redhat-openstack/tripleo-quickstart-utils
```
then it's just a matter of declaring three environment variables, pointing to
three files:
```console
$ export ANSIBLE_CONFIG=/path/to/ansible.cfg
$ export ANSIBLE_INVENTORY=/path/to/hosts
$ export ANSIBLE_SSH_ARGS="-F /path/to/ssh.config.ansible"
```
Where:
**ansible.cfg** must contain at least these lines:
```console
[defaults]
roles_path = /path/to/tripleo-quickstart-utils/roles
```
**hosts** file must be configured with two *controller* and *compute* sections
like these:
```console
undercloud ansible_host=undercloud ansible_user=stack ansible_private_key_file=/path/to/id_rsa_undercloud
overcloud-novacompute-1 ansible_host=overcloud-novacompute-1 ansible_user=heat-admin ansible_private_key_file=/path/to/id_rsa_overcloud
overcloud-novacompute-0 ansible_host=overcloud-novacompute-0 ansible_user=heat-admin ansible_private_key_file=/path/to/id_rsa_overcloud
overcloud-controller-2 ansible_host=overcloud-controller-2 ansible_user=heat-admin ansible_private_key_file=/path/to/id_rsa_overcloud
overcloud-controller-1 ansible_host=overcloud-controller-1 ansible_user=heat-admin ansible_private_key_file=/path/to/id_rsa_overcloud
overcloud-controller-0 ansible_host=overcloud-controller-0 ansible_user=heat-admin ansible_private_key_file=/path/to/id_rsa_overcloud
[compute]
overcloud-novacompute-1
overcloud-novacompute-0
[undercloud]
undercloud
[overcloud]
overcloud-novacompute-1
overcloud-novacompute-0
overcloud-controller-2
overcloud-controller-1
overcloud-controller-0
[controller]
overcloud-controller-2
overcloud-controller-1
overcloud-controller-1
overcloud-controller-0
```
**ssh.config.ansible** can *optionally* contain specific per-host connection
options, like these:
```console
...
...
Host overcloud-controller-0
ProxyCommand ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ConnectTimeout=60 -F /path/to/ssh.config.ansible undercloud -W 192.168.24.16:22
IdentityFile /path/to/id_rsa_overcloud
User heat-admin
StrictHostKeyChecking no
UserKnownHostsFile=/dev/null
...
...
```
In this example to connect to overcloud-controller-0 ansible will use
undercloud ad a ProxyHost
With this setup in place is then possible to launch the playbook:
```console
$ ansible-playbook -vvvv /path/to/tripleo-quickstart-utils/playbooks/overcloud-validate-ha.yml \
-e release=ocata \
-e local_working_dir=/home/rasca/workdir/had-00/workdir \
-e public_physical_network="floating" \
-e floating_ip_cidr="10.0.0.0/24" \
-e public_net_pool_start="10.0.0.191" \
-e public_net_pool_end="10.0.0.198" \
-e public_net_gateway="10.0.0.254"
```
**Note**
The variables above can be declared inside a config.yml file that can be passed
to the ansible-playbook command like this:
```console
$ ansible-playbook -vvvv /path/to/tripleo-quickstart-utils/playbooks/overcloud-validate-ha.yml \
-e @/home/rasca/workdir/had-00/config.yml
```
ansible-playbook -vvvv /home/stack/tripleo-quickstart-utils/playbooks/overcloud-validate-ha.yml -e @/home/stack/config.yml
The result will be the same.
Example Playbook
----------------
The main playbook couldn't be simpler:
```yaml
---
- name: Validate overcloud HA status
hosts: localhost
gather_facts: no
roles:
- tripleo-overcloud-validate-ha
```
But it could also be used at the end of a deployment, like in this file
[baremetal-undercloud-validate-ha.yml](https://github.com/openstack/tripleo-quickstart-extras/blob/master/playbooks/baremetal-undercloud-validate-ha.yml).
License
-------