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
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
containerized-undercloud-docker¶
Verify docker containers are up and ports are open.
Ensure relevant docker containers are up and running, with ports open to listen. We iterate through a list of container names and ports provided in defaults, and ensure the system has those available.
hosts: undercloud
groups: post-deployment, pre-upgrade
parameters:
open_ports: [111, 873, 3000, 3306, 4369, 5000, 5050, 5672, 6000, 6001, 6002, 6379, 6385, 8000, 8004, 8080, 8088, 8774, 8775, 8778, 8787, 8888, 8989, 9000, 9292, 9696, 11211, 15672, 25672, 35357, 39422, {‘port’: 22, ‘search_regex’: ‘OpenSSH’}]
running_containers: [‘glance_api’, ‘heat_api’, ‘heat_api_cfn’, ‘heat_api_cron’, ‘heat_engine’, ‘ironic_api’, ‘ironic_conductor’, ‘ironic_inspector’, ‘ironic_inspector_dnsmasq’, ‘ironic_neutron_agent’, ‘ironic_pxe_http’, ‘ironic_pxe_tftp’, ‘iscsid’, ‘keystone’, ‘keystone_cron’, ‘logrotate_crond’, ‘memcached’, ‘mistral_api’, ‘mistral_engine’, ‘mistral_event_engine’, ‘mistral_executor’, ‘mysql’, ‘neutron_api’, ‘neutron_dhcp’, ‘neutron_l3_agent’, ‘neutron_ovs_agent’, ‘nova_api’, ‘nova_api_cron’, ‘nova_compute’, ‘nova_conductor’, ‘nova_metadata’, ‘nova_placement’, ‘nova_scheduler’, ‘rabbitmq’, ‘swift_account_auditor’, ‘swift_account_reaper’, ‘swift_account_replicator’, ‘swift_account_server’, ‘swift_container_auditor’, ‘swift_container_replicator’, ‘swift_container_server’, ‘swift_container_updater’, ‘swift_object_auditor’, ‘swift_object_expirer’, ‘swift_object_replicator’, ‘swift_object_server’, ‘swift_object_updater’, ‘swift_proxy’, ‘swift_rsync’, ‘tripleo_ui’, ‘zaqar’, ‘zaqar_websocket’]
roles: containerized_undercloud_docker
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
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-counter-stat-validation¶
NFV OvS DPDK Counter Stat Validations.
Run check-nfv-ovsdpdk-counter-stat-validation on the compute ovsdpdk nodes to find out the issues with NFV OvS Dpdk interface statistics.
hosts: {{ compute_ovsdpdk_rolename | default(‘ComputeOvsDpdk’) }}
groups: post-deployment
parameters:
roles: check_nfv_ovsdpdk_counter_stat_validation
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
no-op-firewall-nova-driver¶
Verify NoOpFirewallDriver is set in Nova.
When using Neutron, the firewall_driver option in Nova must be set to NoopFirewallDriver.
hosts: nova_compute
groups: post-deployment
parameters:
nova_conf_path: /var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf
roles: no_op_firewall_nova_driver
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: allovercloud
groups: 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
