tripleo-docs/deploy-guide/source/deployment/ansible_config_download_differences.rst
Amy Marrich (spotz) b84f61a36c EOL Queens and Stein. Added repos for Wallaby
Updated documents to show Queens and Steins as past tense and removed where
possible. Proceedure changes may need to done to the following files:

post_deployment/upgrade/major_upgrade.rst
post_deployment/upgrade/fast_forward_upgrade.rst
post_deployment/upgrade/undercloud.rst
post_deployment/tempest/tempest.rst
features/baremetal_overcloud.rst
features/deployed_server.rst

Wallaby repo section added to the repositories.rst file.

Change-Id: I45ca3ccdb69bad2dfa822558d146e81114eaf7d3
2021-08-17 14:14:07 +00:00

5.8 KiB

Ansible config-download differences

With the Queens release, it became possible to use Ansible to apply the overcloud configuration and this method became the default behavior with the Rockt release.

The feature is fully documented at ansible_config_download, while this page details the differences to the deployer experience with config-download.

Ansible vs. os-collect-config

Previously, TripleO used an agent running on each overcloud node called os-collect-config. This agent periodically polled the undercloud Heat API for software configuration changes that needed to be applied to the node.

os-collect-config ran os-refresh-config and os-apply-config as needed whenever new software configuration changes were detected. This model is a "pull" style model given each node polled the Heat API and pulled changes, then applied them locally.

With config-download, TripleO has switched to a "push" style model. Ansible is run from a central control node which is the undercloud. ansible-playbook is run from the undercloud and software configuration changes are pushed out to each overcloud node via ssh.

With the new model, os-collect-config, os-refresh-config, and os-apply-config are no longer used in a TripleO deployment. The os-collect-config service is now disabled by default and won't start on boot.

Note

Heat standalone software deployments still rely on os-collect-config. They are a type of deployment that can be applied to overcloud nodes directly via Heat outside of the overcloud stack, and without having to do a full stack update of the overcloud stack.

These types of deployments are NOT typically used when doing TripleO.

However, if these deployments are being used in an environment to manage overcloud nodes, then the os-collect-config service must be started and enabled on the overcloud nodes where these types of deployments are applied.

For reference, the Heat CLI commands that are used to create these types of deployments are:

openstack software config create ...
openstack software deployment create ...

If these commands are not being used in the environment, then os-collect-config can be left disabled.

Deployment workflow

The default workflow executed by openstack overcloud deploy takes care of all the necessary changes when using config-download. In both the previous and new workflows, openstack overcloud deploy (tripleoclient) takes care of automating all the steps through Mistral workflow(s). Therefore, existing CLI scripts that called openstack overcloud deploy will continue to work with no changes.

It's important to recognize the differences in the workflow to aid in understanding the deployment and operator experience. Previously, Heat was responsible for:

  1. (Heat) Creating OpenStack resources (Neutron networks, Nova/Ironic instances, etc)
  2. (Heat) Creating software configuration
  3. (Heat) Applying the created software configuration to the Nova/Ironic instances

With config-download, Heat is no longer responsible for the last item of applying the created software configuration as ansible-playbook is used instead.

Therefore, only creating the Heat stack for an overcloud is no longer all that is required to fully deploy the overcloud. Ansible also must be run from the undercloud to apply the software configuration, and do all the required tasks to fully deploy an overcloud such as configuring services, bootstrap tasks, and starting containers.

The new steps are summarized as:

  1. (Heat) Creating OpenStack resources (Neutron networks, Nova/Ironic instances, etc)
  2. (Heat) Creating software configuration
  3. (tripleoclient) Enable tripleo-admin ssh user
  4. (ansible) Applying the created software configuration to the Nova/Ironic instances

See ansible_config_download for details on the tripleo-admin ssh user step.

Deployment CLI output

During a deployment, the expected output from openstack overcloud deploy has changed. Output up to and including the stack create/update is similar to previous releases. Stack events will be shown until the stack operation is complete.

After the stack goes to CREATE_COMPLETE (or UPDATE_COMPLETE), output from the steps to enable the tripleo-admin user via ssh are shown.

config-download Use Cases

config-download exposes the ability to manually run the ansible-playbook command against the playbooks that are generated for the deployment. This leads to many advantages over the older Heat deployment model.

  • Test deployments. Using the ansible-playbook --check --diff deploy_steps_playbook.yaml arguments will not modify an existing deployment. Instead, it will only show any changes that would be made.
  • Development environment testing. Ansible variables can be modified to do quick testing. Once verified, Heat environment templates need to be updated to reflect the change permanently. Then the config-download content should be re-generated by running openstack overcloud deploy --stack-only.
  • Run specific tasks. It is possible to run certain parts of a deployment by using --tags.
  • Prepare the deployment or update ahead of time and then run the playbooks later. The operations around a deployment can be done at different times to minimize risk.
  • Integration with CI/CD. Additional checks and verification can be added to a CI/CD pipeline relating to updating Heat templates and the Ansible config-download content.
  • AWX or Ansible Tower integration. Ansible content can be imported and ran through a scalable and distributed system.