Chapter 4. Certification Tests
The Red Hat OpenStack application policy includes multiple tests each with a series of subtests and checks. Different certifications will require different tests. Following are the certification tests:
4.1. System Report Overview
The System Report test, also known as openstack/sosreport, captures the basic sosreport. Red Hat uses a tool called sos to collect the configuration and diagnostics information from a Red Hat Enterprise Linux(RHEL) system, and to assist the customers in troubleshooting their system and following the recommended practices.
The system report subtest ensures that the sos tool functions as expected on the image/system and captures a basic sosreport. For more information about sosreport, see the link
Success Criteria
- A basic sosreport can be captured from the system under test, and
- The test status will be PASS if a valid rpm version captures and collects the openstack data
4.2. Supportability Test Overview
The Supportability test, also known as openstack/supportable, ensure 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 RHOSP and RHEL that are supported by Red Hat or the Partner.
An OpenStack deployment-under-test refers to the node where the plugin/application-under-test is installed and also the Undercloud Director node.
4.2.1. Kernel Subtest
The Kernel subtest verifies that the kernel utilized by RHEL and included in the deployment-under-test is from Red Hat. The subtest also verifies if the kernel is appropriate and supported for the version of RHEL included in the OpenStack deployment-under-test, and has not been modified. The kernel version may be the original General Availability (GA) version or any subsequent kernel errata released for the RHEL major + minor release.
For more information on Red Hat Enterprise Linux Life Cycle and Kernel Versions, refer Red Hat Enterprise Linux Life Cycle and Red Hat Enterprise Linux Release Dates.
The Kernel subtest also ensures that the kernel is not tainted when running in the environment. For more information about kernel tainting, refer Why is the kernel "tainted" and how are the taint values deciphered?
Success Criteria
The running kernel is a Red Hat released kernel which should not be tainted and can be used with the RHEL version.
4.2.2. Kernel Modules Subtest
The Kernel Modules subtest confirms the loaded kernel modules are from Red Hat, either from the running kernel’s package or a Red Hat Driver Update. For information about Driver Update program see the article, Where can I download Driver Update Program (DUP) disks?.
The kernel module subtest also ensures the kernel modules do not identify as Technology Preview when running in the environment. For information about Technology Preview see the article, What does a "Technology Preview" feature mean?
Success Criteria
The Kernel modules are from Red Hat and supported.
4.2.3. Unsupported Hardware Subtest
The unsupported hardware subtest confirms that the Red Hat kernel has not identified unsupported hardware. This prevents customer production risks which arise from running Red Hat products on unsupported configurations and environments. The kernel is aware of hardware that is not considered supportable for a variety of reasons. When the kernel identifies such hardware it will either provide an unsupported hardware message in the system logs or trigger a kernel taint.
Success Criteria
Tests are run on certified and supported hardware. For a complete list of hardware certified for RHEL 6 or RHEL 7, see the Red Hat Ecosystem Catalog
4.2.4. Installed RPMs Subtest
The installed RPMs subtest confirms that RPM packages installed on the system are from Red Hat and are not modified. This prevents potential significant risks to customer environments and ensures that customers make use of a supported environment.
Non Red Hat packages may be installed if they are necessary to enable the cloud environment. But is expected that they are documented and DO NOT modify or conflict with Red Hat packages/software. This subtest will require detailed review at Red Hat to confirm success or failure if non Red Hat packages are installed.
For more information on Red Hat support policies on third-party software, see, Production Support Scope of Coverage.
Success Criteria
- The installed Red Hat provided RPM packages are from Red Hat product(s) available in the offering
- The installed Red Hat RPM packages are not modified
- The installed Non Red Hat RPM packages are necessary to enable the cloud environment and documented, and
- The installed Non Red Hat RPM packages do not conflict with Red Hat provided packages/software available in Red Hat products included in the offering
4.2.5. SELinux Subtest
Security-Enhanced Linux (SELinux) adds Mandatory Access Control (MAC) to the Linux kernel, and is enabled by default in RHEL. The SELinux subtest confirms that SELinux is running in enforcing mode on the OpenStack deployment-under test.
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. For more information on SELinux in RHEL, see SELinux Users and Administrators Guide
Success Criteria
SELinux is configured and running in enforcing mode on the OpenStack deployment-under-test.
4.3. Director Test
The Director 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 and is targeted specifically for enterprise cloud environments where updates, upgrades and infrastructure control are critical for underlying OpenStack operations.
For more information on installing Red Hat OpenStack Platform Director, see the Director Installation and Usage Guide.
Success Criteria
The deployment under test is originally installed using Red Hat OpenStack Platform Director.
4.4. VNF Testing Configuration Report Test
The VNF testing configuration report test is applicable only for VNF certification. In this test, a Partner selects the operating system on which the VNF is based; provides the link to a report, or uploads a VNF configuration testing report file. The VNF SME, reviews the report that describes the installation, configuration, and testing details that the Partner conducts.
The format of the required report is pre-defined and is at the Partner’s discretion, however it will need to include the following information:
Hardware configuration
- Server make and model
- CPU: make, model, speed, cores, HT
- NIC make/model
- Networking HW make/model
- Storage make/model
- Traffic Generator make/model
Firmware configuration
- Server firmware version
- BMC firmware version
- NIC firmware version
System software configuration
- Version and architecture of Red Hat Enterprise Linux used on the host
- NUMA, Cores, Huge Pages config.
- OpenStack Platform version
- Third party OSP plug-ins used, with versions
- Storage software used
- Architectural / Topology Diagram
VNF configuration
- VNF version
- vCPUs, Memory, storage used in testing
- Dataplane acceleration (ovs-dpdk, sr-iov, etc.)
- Cores allocation - DPDK vs. application
- Bandwidth, IOPS, latency, etc. requirements
Test cases performed:
- Instantiation, termination, scale out/in, healing, HA, and others
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.