XFS ftype check.
Check if there is at least 1 XFS volume with ftype=0 in any deployed node.
Verify existence of deployment images.
This validation checks that images bm-deploy-kernel and bm-deploy-ramdisk exist before deploying the overcloud, and that only one exists by that name.
Node health check.
Check if all overcloud nodes can be connected to before starting a scale-up or an upgrade.
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.
Check correctness of current repositories.
Detect whether the repositories listed in yum repolist can be connected to and that there is at least one repo configured. Detect if there are any unwanted repositories (such as EPEL) enabled.
Stack Health Check.
Check if all stack resources are in a *_COMPLETE state before starting an upgrade.
Verify undercloud fits the disk space requirements to perform an upgrade.
Make sure that the root partition on the undercloud node is large enough before starting an upgrade We first check for an explicit /var mount point since that’s where we store logs and images and if it doesn’t exist, we fall back to /. http://tripleo.org/environments/environments.html#id5
Verify heat-manage purge_deleted is enabled in crontab.
Without a purge_deleted crontab enabled, the heat database can grow very large. This validation checks that the purge_deleted crontab has been set up.
Verify the undercloud fits the RAM requirements.
Verify that the undercloud has enough RAM. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/7/html/Director_Installation_and_Usage/sect-Undercloud_Requirements.html
Verify undercloud services state before running update or upgrade.
Check undercloud status before running a stack update - especially minor update and major upgrade.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.