post-deployment¶
ceph-health¶
Check the status of the ceph cluster.
Uses ceph health to check if cluster is in HEALTH_WARN state and prints a debug message.
hosts: ceph_mon
groups: backup-and-restore, post-deployment, post-ceph
parameters:
tripleo_delegate_to: {{ groups[‘ceph_mon’] | default([]) }}
osd_percentage_min: 0
roles: ceph
Role documentation
check-kernel-version¶
Verify the kernel version contains el8 in its name.
This validation checks the kernel has been upgaded by checking el8 is in kernel (uname -r) version string
hosts: all
groups: post-deployment
parameters:
roles: check_kernel_version
Role documentation
check-manila-policy-file¶
Verify that keystone admin token is disabled.
This validation checks that policy file of manilas configuration folder inside of the container,exists.
hosts: {{ controller_rolename | default(‘Controller’) }}
groups: post-deployment
parameters:
manilas_policy_file: /var/lib/config-data/puppet-generated/manila/etc/manila/policy.yaml
roles: check_manila_policy_file
Role documentation
container-status¶
Ensure container status.
Detect failed containers and raise an error.
hosts: undercloud, allovercloud
groups: backup-and-restore, pre-upgrade, pre-update, post-deployment, post-upgrade
parameters:
roles: container_status
Role documentation
controller-token¶
Verify that keystone admin token is disabled.
This validation checks that keystone admin token is disabled on both undercloud and overcloud controller after deployment.
hosts: [‘undercloud’, “{{ controller_rolename | default(‘Controller’) }}”]
groups: post-deployment
parameters:
keystone_conf_file: /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf
roles: controller_token
Role documentation
controller-ulimits¶
Check controller ulimits.
This will check the ulimits of each controller.
hosts: {{ controller_rolename | default(‘Controller’) }}
groups: post-deployment
parameters:
nofiles_min: 1024
nproc_min: 2048
roles: controller_ulimits
Role documentation
fips-enabled¶
Confirm that undercloud has fips enabled.
Check if the undercloud is ready to deploy an environment using fips.
hosts: all
groups: prep, post-deployment
parameters:
roles: fips_enabled
Role documentation
frr-status¶
FRR Daemons Status Check.
Runs ‘show watchfrr’ and checks for any non-operational daemon.
A failed status post-deployment indicates at least one enabled FRR daemon is not operational.
hosts: all
groups: post-deployment
parameters:
roles: frr_status
Role documentation
healthcheck-service-status¶
Healthcheck systemd services Check.
Check for failed healthcheck systemd services.
hosts: undercloud, allovercloud
groups: backup-and-restore, post-deployment
parameters:
retries_number: 1
delay_number: 1
inflight_healthcheck_services: []
roles: healthcheck_service_status
Role documentation
image-serve¶
Verify image-serve service is working and answering.
Ensures image-serve vhost is configured and httpd is running.
hosts: undercloud
groups: backup-and-restore, pre-upgrade, post-deployment, post-upgrade
parameters:
roles: image_serve
Role documentation
mysql-open-files-limit¶
MySQL Open Files Limit.
Verify the open-files-limit configuration is high enough
https://access.redhat.com/solutions/1598733
hosts: [“{{ controller_rolename | default(‘Controller’) }}”, ‘mysql’]
groups: post-deployment
parameters:
min_open_files_limit: 16384
roles: mysql_open_files_limit
Role documentation
neutron-sanity-check¶
Neutron Sanity Check.
Run neutron-sanity-check on the controller nodes to find out potential issues with Neutron’s configuration.
The tool expects all the configuration files that are passed to the Neutron services.
hosts: {{ controller_rolename | default(‘Controller’) }}
groups: backup-and-restore, post-deployment
parameters:
roles: neutron_sanity_check
Role documentation
nfv-ovsdpdk-zero-packet-loss-check¶
NFV OvS DPDK Zero Packet Loss Validations.
Run check-nfv-ovsdpdk-zero-packet-loss on the compute ovsdpdk nodes to find out the issues with NFV OvS Dpdk configuration. The tool expects all the configuration files that are passed.
hosts: {{ compute_ovsdpdk_rolename | default(‘ComputeOvsDpdk’) }}
groups: post-deployment
parameters:
roles: check_nfv_ovsdpdk_zero_packet_loss
Role documentation
nova-event-callback¶
Nova Event Callback Configuration Check.
This validations verifies that the Nova auth_url in neutron, which is generally enabled by default, is configured correctly It checks the following files on the Overcloud Controller(s):
/etc/neutron/neutron.conf: [nova]/auth_url = ‘http://nova_admin_auth_ip:5000’
hosts: {{ controller_rolename | default(‘Controller’) }}
groups: post-deployment
parameters:
neutron_config_file: /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf
roles: nova_event_callback
Role documentation
nova-svirt¶
Check nova sVirt support.
Ensures all running VM are correctly protected with sVirt
hosts: nova_libvirt
groups: post-deployment, post-upgrade
parameters:
roles: nova_svirt
Role documentation
openstack-endpoints¶
Check connectivity to various OpenStack services.
This validation gets the PublicVip address from the deployment and tries to access Horizon and get a Keystone token.
hosts: undercloud
groups: post-deployment, pre-upgrade, post-upgrade, pre-update, post-update
parameters:
roles: openstack_endpoints
Role documentation
oslo-config-validator¶
Openstack services configuration validation.
This role is intended to leverage the oslo-config-validator on each one of the configuration files found on a deployment. The goal is to quickly catch erroneous configurations.
When called manually, it will also be possible to generate a report returning all the differences between the current configuration and the default configuration
hosts: all
groups: backup-and-restore, post-deployment, post-system-upgrade, post-update, post-upgrade
parameters:
oslo_config_validator_debug: False
oslo_config_validator_report: False
oslo_config_validator_validation: True
oslo_config_validator_invalid_settings: True
oslo_config_validator_report_path: /var/tmp/config_validator_report
oslo_config_validator_report_archive: True
oslo_config_validator_work_path: /var/lib/tripleo-config/oslo_config_validator
oslo_config_validator_checked_services: [‘nova’, ‘cinder’, ‘glance’, ‘heat’, ‘ironic’, ‘placement’, ‘neutron’, ‘keystone’]
roles: oslo_config_validator
Role documentation
overcloud-service-status¶
Verify overcloud services state after running a deployment or an update.
An Ansible role to verify the Overcloud services states after a deployment or an update. It checks the API /os-services and looks for deprecated services (nova-consoleauth) or any down services.
hosts: Undercloud
groups: post-deployment, post-upgrade, post-overcloud-upgrade, post-overcloud-converge
parameters:
overcloud_service_status_debug: False
overcloud_service_api: [‘nova’, ‘cinderv3’]
overcloud_deprecated_services: {‘nova’: [‘nova-consoleauth’]}
roles: overcloud_service_status
Role documentation
ovs-dpdk-pmd-cpus-check¶
Validates OVS DPDK PMD cores from all NUMA nodes..
OVS DPDK PMD cpus must be provided from all NUMA nodes.
A failed status post-deployment indicates PMD CPU list is not configured correctly.
hosts: {{ compute_ovsdpdk_rolename | default(‘ComputeOvsDpdk’) }}
groups: post-deployment
parameters:
roles: ovs_dpdk_pmd
Role documentation
pacemaker-status¶
Check the status of the pacemaker cluster.
This runs pcs status and checks for any failed actions.
A failed status post-deployment indicates something is not configured correctly. This should also be run before upgrade as the process will likely fail with a cluster that’s not completely healthy.
This validation fails if pacemaker service is found failed or inactive.
hosts: {{ controller_rolename | default(‘Controller’) }}
groups: backup-and-restore, post-deployment
parameters:
roles: pacemaker_status
Role documentation
rabbitmq-limits¶
Rabbitmq limits.
Make sure the rabbitmq file descriptor limits are set to reasonable values.
hosts: {{ controller_rolename | default(‘Controller’) }}
groups: post-deployment
parameters:
min_fd_limit: 16384
roles: rabbitmq_limits
Role documentation
stonith-exists¶
Validate stonith devices.
Verify that stonith devices are configured for your OpenStack Platform HA cluster. We don’t configure stonith device with TripleO Installer. Because the hardware configuration may be differ in each environment and requires different fence agents. How to configure fencing please read https://access.redhat.com/documentation/en/red-hat-openstack-platform/8/paged/director-installation-and-usage/86-fencing-the-controller-nodes
hosts: {{ controller_rolename | default(‘Controller’) }}
groups: post-deployment
parameters:
roles: stonith_exists
Role documentation
tls-everywhere-post-deployment¶
Confirm that overcloud nodes are setup correctly.
Checks that overcloud nodes are registered with IdM and that all certs being tracked by certmonger are in the MONITORING state.
hosts: allovercloud
groups: post-deployment
parameters:
roles: tls_everywhere
Role documentation
tripleo-haproxy¶
TripleO HAProxy configuration.
Verify the HAProxy configuration has recommended values.
hosts: haproxy
groups: post-deployment
parameters:
config_file: /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg
global_maxconn_min: 20480
defaults_maxconn_min: 4096
defaults_timeout_queue: 2m
defaults_timeout_client: 2m
defaults_timeout_server: 2m
defaults_timeout_check: 10s
roles: tripleo_haproxy
Role documentation
