Language and Page Formatting Options
Chapter 15. Using the validation framework
Red Hat OpenStack Platform includes a validation framework that you can use to verify the requirements and functionality of the undercloud and overcloud. The framework includes two types of validations:
Manual Ansible-based validations, which you execute through the
openstack tripleo validatorcommand set.
- Automatic in-flight validations, which execute during the deployment process.
You must understand which validations you want to run, and skip validations that are not relevant to your environment. For example, the pre-deployment validation includes a test for TLS-everywhere. If you do not intend to configure your environment for TLS-everywhere, this test fails. Use the
--validation option in the
openstack tripleo validator run command to refine the validation according to your environment.
15.1. Ansible-based validations
During the installation of Red Hat OpenStack Platform director, director also installs a set of playbooks from the
openstack-tripleo-validations package. Each playbook contains tests for certain system requirements and a set of groups that define when to run the test:
- Validations that run a no-op (no operation) task to verify to workflow functions correctly. These validations run on both the undercloud and overcloud.
Validations that check the hardware configuration of the undercloud node. Run these validation before you run the
openstack undercloud installcommand.
- Validations that check that the environment meets the requirements to be able to deploy OpenShift on OpenStack.
- Validations to run before the nodes introspection using Ironic Inspector.
Validations to run before the
openstack overcloud deploycommand.
- Validations to run after the overcloud deployment has finished.
- Validations to validate your OpenStack deployment before an upgrade.
- Validations to validate your OpenStack deployment after an upgrade.
15.2. Listing validations
openstack tripleo validator list command to list the different types of validations available.
$ source ~/stackrc
openstack tripleo validator listcommand:
To list all validations, run the command without any options:
$ openstack tripleo validator list
To list validations in a group, run the command with the
$ openstack tripleo validator list --group prep
For a full list of options, run
openstack tripleo validator list --help.
15.3. Running validations
To run a validation or validation group, use the
openstack tripleo validator run command. To see a full list of options, use the
openstack tripleo validator run --help command.
$ source ~/stackrc
Create and validate a static inventory file called
$ tripleo-ansible-inventory --static-yaml-inventory inventory.yaml $ openstack tripleo validator run --group pre-introspection -i inventory.yaml
openstack tripleo validator runcommand:
To run a single validation, enter the command with the
--validationoption and the name of the validation. For example, to check the memory requirements of each node, enter
$ openstack tripleo validator run --validation check-ram
If the overcloud uses a plan name that is different to the default
overcloudname, set the plan name with the
$ openstack tripleo validator run --validation check-ram --plan myovercloud
To run multiple specific validations, use the
--validationoption with a comma-separated list of the validations that you want to run. For more information about viewing the list of available validations, see Listing validations.
To run all validations in a group, enter the command with the
$ openstack tripleo validator run --group prep
To view detailed output from a specific validation, run the
openstack tripleo validator show run --fullcommand against the UUID of the specific validation from the report:
$ openstack tripleo validator show run --full <UUID>
15.4. Viewing validation history
Director saves the results of each validation after you run a validation or group of validations. View past validation results with the
openstack tripleo validator show history command.
- You have run a validation or group of validations.
$ source ~/stackrc
View a list of all validations:
$ openstack tripleo validator show history
To view history for a specific validation type, run the same command with the
$ openstack tripleo validator show history --validation ntp
View the log for a specific validation UUID with the
openstack tripleo validator show run --fullcommand:
$ openstack tripleo validator show run --full 7380fed4-2ea1-44a1-ab71-aab561b44395
15.5. Validation framework log format
After you run a validation or group of validations, director saves a JSON-formatted log from each validation in the
/var/logs/validations directory. You can view the file manually or use the
openstack tripleo validator show run --full command to display the log for a specific validation UUID.
Each validation log file follows a specific format:
- The Ansible UUID for the validation.
- The Ansible name for the validation.
- The start date and time for when you ran the validation.
Each validation log contains three main parts:
plays section contains information about the tasks that the director performed as part of the validation:
A play is a group of tasks. Each
playsection contains information about that particular group of tasks, including the start and end times, the duration, the host groups for the play, and the validation ID and path.
The individual Ansible tasks that director runs to perform the validation. Each
taskssection contains a
hostssection, which contains the action that occurred on each individual host and the results from the execution of the actions. The
taskssection also contains a
tasksection, which contains the duration of the task.
stats section contains a basic summary of the outcome of all tasks on each host, such as the tasks that succeeded and failed.
If any tasks failed or caused a warning message during a validation, the
validation_output contains the output of that failure or warning.
15.6. Validation framework log output formats
The default behaviour of the validation framework is to save validation logs in JSON format. You can change the output of the logs with the
ANSIBLE_STDOUT_CALLBACK environment variable.
To change the validation output log format, run a validation and include the
--extra-env-vars ANSIBLE_STDOUT_CALLBACK=<callback> option:
$ openstack tripleo validator run --extra-env-vars ANSIBLE_STDOUT_CALLBACK=<callback> --validation check-ram
<callback> with an Ansible output callback. To view a list of the standard Ansible output callbacks, run the following command:
$ ansible-doc -t callback -l
The validation framework includes the following additional callbacks.
The framework saves JSON-formatted validation results as a log file in
/var/logs/validations. This is the default callback for the validation framework.
- The framework displays JSON-formatted validation results on screen.
The framework sends JSON-formatted validation results to an external logging server. You must also include additional environment variables for this callback:
- The URL for the external server.
- The port for the API entry point of the external server. The default port in 8989.
Set these environment variables with additional
$ openstack tripleo validator run --extra-env-vars ANSIBLE_STDOUT_CALLBACK=http_json \ --extra-env-vars HTTP_JSON_SERVER=http://logserver.example.com \ --extra-env-vars HTTP_JSON_PORT=8989 \ --validation check-ramImportant
Before you use the
http_jsoncallback, you must add
callback_whitelistparameter in your
callback_whitelist = http_json
15.7. In-flight validations
Red Hat OpenStack Platform includes in-flight validations in the templates of composable services. In-flight validations verify the operational status of services at key steps of the overcloud deployment process.
In-flight validations run automatically as part of the deployment process. Some in-flight validations also use the roles from the