Chapter 13. Configuring the overcloud with Ansible

• Director creates a new deployment plan based on openstack-tripleo-heat-templates and includes any environment files and parameters to customize the plan.
• Director uses heat to interpret the deployment plan and create the overcloud stack and all descendant resources. This includes provisioning nodes with the OpenStack Bare Metal service (ironic).
• Heat also creates the software configuration from the deployment plan. Director compiles the Ansible playbooks from this software configuration.
• Director generates a temporary user (tripleo-admin) on the overcloud nodes specifically for Ansible SSH access.
• Director downloads the heat software configuration and generates a set of Ansible playbooks using heat outputs.
• Director applies the Ansible playbooks to the overcloud nodes using ansible-playbook.

• The overcloud data schema: Applying a previous version of the working directory software configuration does not undo data migration and schema changes.
• The hardware layout of the overcloud: Reverting to previous software configuration does not undo changes related to overcloud hardware, such as scaling up or down.
• The heat stack: Reverting to earlier revisions of the working directory has no effect on the configuration stored in the heat stack. The heat stack creates a new version of the software configuration that applies to the overcloud. To make permanent changes to the overcloud, modify the environment files applied to the overcloud stack before you rerun the openstack overcloud deploy command.

Prerequisites

• A successful undercloud installation.
• Overcloud nodes ready for deployment.
• Heat environment files that are relevant to your specific overcloud customization.

Prerequisites

• A successful undercloud installation.
• Overcloud nodes ready for deployment.
• Heat environment files that are relevant to your specific overcloud customization.

Prerequisites

• An overcloud deployed with the one of the following methods:

  • Standard method that combines provisioning and configuration process
  • Separate provisioning and configuration processes

Additional information

• The working directory contains a playbook called deploy_steps_playbook.yaml, which manages the overcloud configuration tasks. To view this playbook, run the following command:

  $ less deploy_steps_playbook.yaml

  The playbook uses various task files contained in the working directory. Some task files are common to all OpenStack Platform roles and some are specific to certain OpenStack Platform roles and servers.

• The working directory also contains sub-directories that correspond to each role that you define in your overcloud roles_data file. For example:

  $ ls Controller/

  Each OpenStack Platform role directory also contains sub-directories for individual servers of that role type. The directories use the composable role hostname format:

  $ ls Controller/overcloud-controller-0

• The Ansible tasks in deploy_steps_playbook.yaml are tagged. To see the full list of tags, use the CLI option --list-tags with ansible-playbook:

  $ ansible-playbook -i tripleo-ansible-inventory.yaml --list-tags deploy_steps_playbook.yaml

  Then apply tagged configuration using the --tags, --skip-tags, or --start-at-task with the ansible-playbook-command.sh script:

  $ ./ansible-playbook-command.sh --tags overcloud

  1. When you run the config-download playbooks against the overcloud, you might receive a message regarding the SSH fingerprint for each host. To avoid these messages, include --ssh-common-args="-o StrictHostKeyChecking=no" when you run the ansible-playbook-command.sh script:

     $ ./ansible-playbook-command.sh --tags overcloud --ssh-common-args="-o StrictHostKeyChecking=no"

Prerequisites

• A successful undercloud installation.
• Overcloud nodes ready for deployment.
• Heat environment files that are relevant to your specific overcloud customization.

Additional information

• The config-download directory contains a playbook called deploy_steps_playbook.yaml, which runs the overcloud configuration. To view this playbook, run the following command:

  $ less deploy_steps_playbook.yaml

  The playbook uses various task files contained in the working directory. Some task files are common to all OpenStack Platform roles and some are specific to certain OpenStack Platform roles and servers.

• The config-download directory also contains sub-directories that correspond to each role that you define in your overcloud roles_data file. For example:

  $ ls Controller/

  Each OpenStack Platform role directory also contains sub-directories for individual servers of that role type. The directories use the composable role hostname format:

  $ ls Controller/overcloud-controller-0

• The Ansible tasks in deploy_steps_playbook.yaml are tagged. To see the full list of tags, use the CLI option --list-tags with ansible-playbook:

  $ ansible-playbook -i tripleo-ansible-inventory.yaml --list-tags deploy_steps_playbook.yaml

  Then apply tagged configuration using the --tags, --skip-tags, or --start-at-task with the ansible-playbook-command.sh script:

  $ ansible-playbook \
    -i inventory.yaml \
    -e gather_facts=true \
    -e @global_vars.yaml \
    --private-key ~/.ssh/id_rsa \
    --become \
    --tags overcloud \
    ~/config-download/deploy_steps_playbook.yaml

  1. When you run the config-download playbooks against the overcloud, you might receive a message regarding the SSH fingerprint for each host. To avoid these messages, include --ssh-common-args="-o StrictHostKeyChecking=no" to your ansible-playbook command:

     $ ansible-playbook \
       -i inventory.yaml \
       -e gather_facts=true \
       -e @global_vars.yaml \
       --private-key ~/.ssh/id_rsa \
       --ssh-common-args="-o StrictHostKeyChecking=no" \
       --become \
       --tags overcloud \
       ~/config-download/deploy_steps_playbook.yaml

• When you use ansible-playbook CLI arguments such as --tags, --skip-tags, or --start-at-task, do not run or apply deployment configuration out of order. These CLI arguments are a convenient way to rerun previously failed tasks or to iterate over an initial deployment. However, to guarantee a consistent deployment, you must run all tasks from deploy_steps_playbook.yaml in order.

• You can not use the --start-at-task arguments for certain tasks that use a variable in the task name. For example, the --start-at-task arguments does not work for the following Ansible task:

  - name: Run puppet host configuration for step {{ step }}

• If your overcloud deployment includes a director-deployed Ceph Storage cluster, you cannot skip step1 tasks when you use the --check option unless you also skip external_deploy_steps tasks.
• You can set the number of parallel Ansible tasks with the --forks option. However, the performance of config-download operations degrades after 25 parallel tasks. For this reason, do not exceed 25 with the --forks option.