Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 8. IPI certification tests
The certification includes self-check, supportable, director_undercloud and bare metal tests.
8.1. Self check test
The self-check test confirms that all required software packages for certification are installed and unaltered, ensuring the test environment is ready for certification. Certification packages must not be modified for testing or any other purpose.
Success Criteria
The test environment includes all necessary certification packages and the packages have not been modified.
8.2. Supportable test
The supportable test, also known as baremetal/supportable, ensures that the test environment is compliant with Red Hat’s support policy. The test confirms that the test node (an OpenStack deployment under test) consists only of components supported by Red Hat (Red Hat OpenStack Platform, Red Hat Enterprise Linux).
An OpenStack deployment under test refers to the node where the plugin or application under test is installed.
Supportability tests must be run on both the control node and the compute node.
This test is required for all OpenStack software certifications.
Compute Node Considerations:
- If your kernel is not updated, ensure that you update the kernel test section to verify that the compute uses the GA kernel to prevent review exit. Review will need to account for the status of RHEL certification.
- Driver Update Programs (DUPs) are acceptable on the compute node but will cause the test to exit review. Review needs to confirm the DUP that aligns with the one used in the corresponding RHEL certification.
The baremetal/supportable tests include the following subtests:
8.2.1. Kernel subtest
The kernel subtest checks the kernel module running on the test environment. The version of the kernel can be either the original General Availability (GA) version or any subsequent kernel update released for the RHEL major and minor releases.
The kernel subtest also ensures that the kernel is not tainted when running in the environment.
Success criteria
- The running kernel is a Red Hat kernel.
- The running kernel is released by Red Hat for use with the RHEL version.
- The running kernel is not tainted.
- The running kernel has not been modified.
8.2.2. Kernel modules subtest
The kernel modules subtest verifies that loaded kernel modules are released by Red Hat, either as part of the kernel’s package or added through a Red Hat Driver Update. The kernel module subtest also ensures that kernel modules do not identify as Technology Preview.
Success criteria
- The kernel modules are released by Red Hat and supported.
Additional resources
8.2.3. Hardware Health subtest
The Hardware Health subtest checks the system’s health by testing if the hardware is supported, meets the requirements, and has any known hardware vulnerabilities. The subtest does the following:
Checks that the Red Hat Enterprise Linux (RHEL) kernel does not identify hardware as unsupported. When the kernel identifies unsupported hardware, it will display an unsupported hardware message in the system logs and/or trigger an unsupported kernel taint. This subtest prevents customers from possible production risks which may arise from running Red Hat products on unsupported configurations and environments.
In hypervisor, partitioning, cloud instances, and other virtual machine situations, the kernel may trigger an unsupported hardware message or taint based on the hardware data presented to RHEL by the virtual machine (VM).
Checks that the Host Under Test (HUT) meets the minimum hardware requirements.
- RHEL 8 and 9: Minimum system RAM should be 1.5GB, per CPU logical core count.
- RHEL 7: Minimum system RAM should be 1GB, per CPU logical core count.
- Checks if the kernel has reported any known hardware vulnerabilities, if those vulnerabilities have mitigations and if those mitigations have resolved the vulnerability. Many mitigations are automatic to ensure that customers do not need to take active steps to resolve vulnerabilities. In some cases this is not possible; where most of these remaining cases require changes to the configuration of the system BIOS/firmware which may not be modifiable by customers in all situations.
- Confirms the system does not have any offline CPUs.
- Confirms if Simultaneous Multithreading (SMT) is available, enabled, and active in the system.
Failing any of these tests will result in a WARN from the test suite and should be verified by the partner to have correct and intended behavior.
Success criteria
- The kernel does not have the UNSUPPORTEDHARDWARE taint bit set.
- The kernel does not report an unsupported hardware system message.
- The kernel should not report any vulnerabilities with mitigations as vulnerable.
- The kernel does not report the logic core to installed memory ratio as out of range.
- The kernel does not report CPUs in an offline state.
8.2.4. Installed RPMs subtest
The installed RPMs subtest verifies that RPM packages installed on the system are released by Red Hat and not modified. Modified packages may introduce risks and impact the supportability of the customer’s environment. You might install non-Red Hat packages if necessary, but you must add them to your product’s documentation, and they must not modify or conflict with any Red Hat packages.
Red Hat will review the output of this test if you install non-Red Hat packages.
Success criteria
- The installed Red Hat RPMs are not modified.
- The installed non-Red Hat RPMs are necessary and documented.
- The installed non-Red Hat RPMs do not conflict with Red Hat RPMs or software.
Additional resources
8.2.5. System report subtest
Red Hat uses a tool called sos to collect configuration and diagnostics information from a RHEL system. The sos tool assists customers in troubleshooting a RHEL system and following the recommended practices.
The System Report subtest ensures that the sos tool functions as expected on the image or system and captures a basic sosreport.
Success Criteria
The RHCERT tool captures a basic sosreport on the OpenStack deployment under test.
Additional resources
- For more information about sosreport, see What is an sosreport and how to create one in Red Hat Enterprise Linux?
8.2.6. SELinux subtest
Confirms that SELinux is running in enforcing mode on the OpenStack deployment-under test.
Security-Enhanced Linux (SELinux) adds Mandatory Access Control (MAC) to the Linux kernel, and is enabled by default in Red Hat Enterprise Linux.
SELinux policy is administratively-defined, enforced system-wide, and is not set at user discretion, reducing vulnerability to privilege escalation attacks helping limit the damage made by configuration mistakes. If a process becomes compromised, the attacker only has access to the normal functions of that process, and the files that the process has been configured to.
Success Criteria
SELinux is configured and running in enforcing mode on the OpenStack deployment under test.
Additional resources
- For more information on SELinux in RHEL, see SELinux Users and Administrators Guide.
8.3. Director_undercloud test
The Director_undercloud test, also known as openstack/director, ensures that the deployment-under-test is originally installed using Red Hat OpenStack Platform Director. This test is required for all OpenStack software certifications.
Red Hat OpenStack Platform Director is the supported toolset for installing and managing a Red Hat OpenStack Platform environment in production. It helps in easy installation of a lean and robust OpenStack cloud. It is specifically targeted for enterprise cloud environments where updates, upgrades, and infrastructure control are critical for underlying OpenStack operations.
Success Criteria
The deployment under test is originally installed using Red Hat OpenStack Platform Director.
Additional resources
- For more information on installing Red Hat OpenStack Platform Director, see Director Installation and Usage Guide.
8.4. Bare Metal test
The following sub-tests comprise the bare metal test. The tests perform enrolling, inspection and deployments to validate the bare metal node.
8.4.1. Bare Metal InstackStackrc validation
Validates the instackenv.json and stackrc files.
Success Criteria
-
Checks if the
instackenv.jsonandstackrcfiles exist in the specified location and validate the content ofinstackenv.jsonfile, and - Requires validation check if the file is a valid json file and the specified BMC IPs are reachable.
8.4.2. Bare Metal driver validation
Compares the drivers configured on the HUT with the drivers supported by Red Hat. If a driver mismatch occurs the subtest generates a Review state and exits.The drivers supported by Red Hat are part of the test suite
Success Criteria
-
The specified driver should match with the driver in
instackenv.jsonfile, and -
If the drivers do not match the test will exit with a Review state. In this scenario, the Red Hat certification team will manually check the
instackenv.jsonfile and the specified driver to validate if the drivers are supported drivers.
8.4.3. Bare Metal undercloud validation
Checks if tests are running from the undercloud node. If the tests are not running from this node, the test fails and you need to rerun the test.
Success Criteria
Testing undercloud artifacts to check if the test ran from the undercloud node.
The undercloud node is the valid node.
8.4.4. Bare Metal enrolling test
Checks if the bare-metal driver is successfully able to enroll the hardware node using the BMC IP. The enrollment process requires driver to communicate properly with BMC IP. The BMC changes the Power state and Provisioning state of the enrolled nodes to off and available.
The test also checks if the stack overcloud exists and if the nodes are already added. It deletes the stack and nodes if they exist, and then tries to enroll nodes based on the instackenv.json file. The test is failed if any of the stages fail.
Success Criteria
Enrolled nodes are expected to be in Power and Provisioning state.
8.4.5. Bare Metal inspecting test
Once the operator sets the required driver_info fields, BareMetalInspectingTest allows Bare Metal service to discover required node properties.
Success Criteria
Node properties should be correctly populated so that BMC can gather hardware details based on the instructions provided by the driver.
8.4.6. Bare Metal deploying test
Once the inspection is completed successfully,the Bare Metal Deploying Test will try to nova boot two virtual machines by creating and assigning a custom flavor to the nodes. This helps to check if BMCs can provide instances with the required boot images, and then try to boot up the instances.
Success Criteria
Start of VMs' with Active status attached to them.
8.4.7. Bare Metal redeploying test
Tries to redeploy nova instances.
Success Criteria
All the stages covered previously should pass in the redeploy too. The test enrolls and inspects the hardware instances, deploys the instances based on the enroll and inspect stages.
