Technical resources
Optimizing Red Hat Enterprise Linux hardware certification testing
Our OEM and silicon hardware certification partners spend many hours testing independently, and jointly with Red Hat, to see to it that customers are successful with hardware deployments on Red Hat’s bare metal, virtual, and cloud platforms.
With thousands of components across hundreds of systems it can be time consuming to test every combination. This is where a well-prepared leverage strategy will help create a faster time-to-completion of Red Hat Enterprise Linux (RHEL) hardware certifications while helping to maintain the high quality and competency of supportability, security, and life cycle management our joint customers expect.
What is leverage?
Leverage is a RHEL hardware certification concept that allows partners to reuse certification test results for a given component on a given system certification across a series of other like systems for credit in their certification test plans. We call it leverage because partners can "leverage" their existing testing against a component and system to additional configurations. For example, if you've tested a system that has a component against RHEL 8, you can leverage that testing to another system using the same component.
This practice is established by recognizing and requiring that the device is the same in each system, that successful certification test results for the given component have already been provided and accredited, and that the partner has already conducted its own independent testing of the Red Hat platform with the given component in each system where leverage is requested.
Leverage strategies
Leverage is not a free-for-all but based on existing testing already being conducted so now we need to optimize for conducting the right RHEL hardware certification testing. An effective leverage strategy can help limit testing and testing time spent during RHEL hardware certification is meaningful and valuable testing by minimizing redundant inconsequential testing.
Here are a couple of different strategies to consider.
Method 1: create a reference matrix document
The first method is to create a reference matrix document for each RHEL major version where every component that is tested is recorded, including in which system certification, with which minor version and what the test ID is as they are conducted and credited.
Then, when the same component is encountered later in another system the document can be referenced to help determine if the component has already been tested in RHEL hardware certification and what the required IDs are to request credit via leveraging.
Before requesting leverage or providing any IDs, you need to validate internally that it is indeed the same device in both systems and that the new component+system combination has already been qualified. Many components have similar or identical names even though they are different, and many systems include components with the similar or identical names but are, in fact, bespoke to the system.
For example, two systems may have a completely different implementation of a component with different features and capabilities because of physical requirements (like slot height, power, cooling) or market requirements (datacenter, industrial, edge) where the component is actually bespoke between the two systems and leverage would not be allowed.
Once validated, instead of standing up a test environment to retest the same card the test results ID from the reference matrix can be provided in the certification test plan for this component in the new system certification request.
This method has the lowest stand up cost and is good if you are inheriting a body of already certified systems without any knowledge of where components have already been tested. You can start this process at any point and build up from there.
One negative to this test method is that it's reactive. This means hardware and test scheduling can be difficult, and requires strong continuity of test methods and information. An organization that uses third party testing may have trouble with this continuity, meaning that the leverage strategy can't work.
Method 2: Use leverage pools
The second method is leverage pools. A leverage pool is a series of special unpublished component certifications that a system partner conducts to establish a component list intended for use during later system certifications via leveraging.
To create a leverage pool, select a component that you intend to leverage across a series of systems. Then instead of certifying that component within a system certification, create a new component certification request. Request to have the certification type changed to “leverage pool (private)”. When this is selected, the component will receive its own individual test plan limited to the component to be conducted as normal.
Once completed, the component certification will not appear in the catalog but will continue to appear in your list of certifications. Not listing the component is often desirable and necessary as most components are known by the chip and chip vendor name—not the system and system vendor name—so only the chip vendor would be allowed to certify the component for publishing.
This method requires more forethought and planning into which components to conduct leverage pool certifications and which ones to do within a system certification. Not all components are leverageable and not all leverageable components will be reused in multiple systems in order to benefit from the upfront effort of the leverage pool component certification. However, it ensures that the matrix list is discoverable at any time by searching in the certification tool for the leverage pool certifications.
Leverage pools are also very effective during next-generation launches, of either Red Hat platforms or hardware platforms, as they allow work to be both serialized and parallelized. For example, a new generation of servers that all use the same series of network cards could utilize leverage pool certification for the network cards, conducting the testing back-to-back during the same day.
Then as the system certifications begin testing, each of the system certification could populate the same list of leverage IDs in their individual test plans covering a double-digit percent of the certification requirements across the entire series of servers.
These two strategies are not mutually exclusive and can be mixed, along with strategies that may help achieve a more efficient rate of effective certification testing for you, your company, Red Hat and our joint customers.
Resources
Red Hat hardware certification partners are encouraged to utilize leverage and leverage pools but are not required to do so. A full bespoke round of testing every component in each and every system will continue to qualify for hardware certification testing requirements.
The RHEL hardware certification policies, including the policies around leverage and leverage pools can be found in the RHEL hardware certification policy guide on the customer portal.
