TripleO and Ansible (Part 2)

In my last post, I covered some of the details about using Ansible to deploy
with TripleO. If you haven’t read that yet, I suggest starting there:
https://blogslagle.wordpress.com/2017/12/11/tripleo-and-ansible-deployment-part-1/

I’ll now cover interacting with Ansible more directly.

When using --config-download as a deployment argument, a Mistral workflow will be enabled that runs ansible-playbook to apply the deployment and configuration data to each node. When the deployment is complete, you can interact with the files that were created by the workflow.

Let’s take a look at how to do that.

You need to have a shell on the Undercloud. Since the files used by the workflow potentially contain sensitive data, they are only readable by the mistral user or group. So either become the root user, or add your interactive shell user account (typically “stack”) to the mistral group:

sudo usermod -a -G mistral stack
# Activate the new group
newgrp mistral

Once the permissions are sorted, change to the mistral working directory for
the config-download workflows:

cd /var/lib/mistral

Within that directory, there will be directories named according to the Mistral
execution uuid. An easy way to find the most recent execution of
config-download is to just cd into the most recently created directory and list
the files in that directory:

cd 2747b55e-a7b7-4036-82f7-62f09c63d671
ls

The following files (or a similar set, as things could change) will exist:

ansible.cfg
ansible.log
ansible-playbook-command.sh
common_deploy_steps_tasks.yaml
Controller
deploy_steps_playbook.yaml
deploy_steps_tasks.yaml
external_deploy_steps_tasks.yaml
external_post_deploy_steps_tasks.yaml
group_vars
ssh_private_key
templates
tripleo-ansible-inventory
update_steps_playbook.yaml
update_steps_tasks.yaml
upgrade_steps_playbook.yaml
upgrade_steps_tasks.yaml

All the files that are needed to re-run ansible-playbook are present. The exact ansible-playbook command is saved in ansible-playbook-command.sh. Let’s take a look at that file:

$ cat ansible-playbook-command.sh
 #!/bin/bash

OS_AUTH_TOKEN="gAAAAABaMD3b3UQziKRzm2jjutrxBbYgqfWSTZWAMXyU5DcTA83Nn28eBVUvr0darSl0LcF3kb-I7OYnMxAp3dBs39ejrINYmsuBmT7ZE3SjYjWqtgivQyYWOHJmgKscl2VuBnWF8Jq-kd3wOHpHQVpJ0ILls35uFPUQvf91ckpr2QsEg67i9Ys"
 OS_AUTH_URL="http://192.168.24.1:5000/v3"
 OS_PROJECT_NAME="admin"
 OS_USERNAME="admin"
 ANSIBLE_CONFIG="/var/lib/mistral/2747b55e-a7b7-4036-82f7-62f09c63d671/ansible.cfg"
 HOME="/var/lib/mistral/2747b55e-a7b7-4036-82f7-62f09c63d671"

ansible-playbook -v /var/lib/mistral/2747b55e-a7b7-4036-82f7-62f09c63d671/deploy_steps_playbook.yaml --user tripleo-admin --become --ssh-extra-args "-o StrictHostKeyChecking=no" --timeout 240 --inventory-file /var/lib/mistral/2747b55e-a7b7-4036-82f7-62f09c63d671/tripleo-ansible-inventory --private-key /var/lib/mistral/2747b55e-a7b7-4036-82f7-62f09c63d671/ssh_private_key $@

You can see how the call to ansible-playbook is reproduced in this script. Also notice that $@ is used to pass any additional arguments directly to ansible-playbook when calling this script, such as --check, --limit, --tags, --start-at-task, etc.

Some of the other files present are:

  • tripleo-ansible-inventory
    • Ansible inventory file containing hosts and vars for all the Overcloud nodes.
  • ansible.log
    • Log file from the last run of ansible-playbook.
  • ansible.cfg
    • Config file used when running ansible-playbook.
  • ansible-playbook-command.sh
    • Executable script that can be used to rerun ansible-playbook.
  • ssh_private_key
    • Private ssh key used to ssh to the Overcloud nodes.

Within the group_vars directory, there is a corresponding file per role. In my
example, I have a Controller role. If we take a look at group_vars/Controller we see it contains:

$ cat group_vars/Controller
Controller_pre_deployments:
- HostsEntryDeployment
- DeployedServerBootstrapDeployment
- UpgradeInitDeployment
- InstanceIdDeployment
- NetworkDeployment
- ControllerUpgradeInitDeployment
- UpdateDeployment
- ControllerDeployment
- SshHostPubKeyDeployment
- ControllerSshKnownHostsDeployment
- ControllerHostsDeployment
- ControllerAllNodesDeployment
- ControllerAllNodesValidationDeployment
- ControllerArtifactsDeploy
- ControllerHostPrepDeployment

Controller_post_deployments: []

The <RoleName>_pre_deployments and <RoleName>_post_deployments variables contain the list of Heat deployment names to run for that role. Suppose we wanted to just rerun a single deployment. That command would be:

$ ./ansible-playbook-command.sh --tags pre_deploy_steps -e Controller_pre_deployments=ControllerArtifactsDeploy -e force=true

That would run just the ControllerArtifactsDeploy deployment. Passing -e force=true is necessary to force the deployment to rerun. Also notice we restrict what tags get run with --tags pre_deploy_steps.

For documentation on what tags are available see:
https://docs.openstack.org/tripleo-docs/latest/install/advanced_deployment/ansible_config_download.html#tags

Finally, suppose we wanted to just run the 5 deployment steps that are the same for all nodes of a given role. We can use --limit <RoleName>, as the role names are defined as groups in the inventory file. That command would be:

$ ./ansible-playbook-command.sh --tags deploy_steps --limit Controller

I hope this info is helpful. Let me know what you want to see next.

Advertisements

One thought on “TripleO and Ansible (Part 2)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s