Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 7. Testing requirements for cloud instance
Understand the process followed by the Red Hat CCSP Instance team to create a test plan for a system or hardware component.
7.1. Overview of test plan
A certification engineer creates a test plan by following these steps:
- Determine the Instance Types to be covered by the certification.
- Define and determine the hardware features based on the specification provided.
- Remove unsupported operating system features.
- Apply the minimum test set criteria.
- Add the install, boot, and kdump requirements.
- Apply any other additional policy requirements.
- Freeze and provide the testplan to the partner.
The created test plan will list the tests to be run against the Instance type features to achieve certification.
7.2. Instance Type and its specifications
Red Hat Cloud Instance Type Certification certifies a specific Instance Type. Red Hat defines an Instance Type as a unique name with a specific definition of physical and virtual hardware features. The specification is inclusive of all Integrated Hardware and Optional Hardware features described by the CCSP Partner.
Integrated-Hardware is a hardware feature present in all configurations of an Instance Type. Optional-Hardware is hardware or features which are only present in some configurations of an Instance Type.
An Instance Type may be available in multiple sizes using a tiered naming scheme. Sizes with tiered naming schemes are encouraged and supported by Red Hat Cloud Instance Type Certification. A tiered naming scheme is any naming scheme which includes a hierarchical collection of Instance Type. When employing tiered naming schemes for the purposes of certification the specification is considered to include all Instance Type and sizes which would reasonably be represented by the name provided in the certification request.
Example
An Instance Type with the names t1 is available in the sizes t1A, and t1B; the certification requirements would reflect the collection specification across the t1A and t1B sizes. The resulting certifications would be for the t1A and t1B sizes under the t1 Instance Type.
Red Hat may alter the listed Instance Type name for clarity; for example in NUMA and cluster situations when a quantity of systems/nodes alters the specification , Red Hat may add "(up to 2 nodes)" to the Instance Type name.
7.3. Hardware features
The Hardware features identified in each Instance Type specification aligns to a hardware class, mentioned in Hardware requirements by class. These features along with the requirements outlined in Hardware requirements by class forms the basis of the test plan. Every feature will receive a clear alignment with a requirement in the test plan. This complete set will then continue to be refined in the next steps which will ensure an efficient and effective use of your and our resources for an assured customer success.
7.4. Integrated Hardware
All Integrated Hardware features, CPU options, memory options, and any other feature a customer cannot remove from an instance must be tested.
Specific features of integrated hardware may later be excluded from the certification testing requirement if they qualify for exclusion based on the policies outlined in Non-OS-Features or Minimum-Test-Set sections.
7.5. Optional Hardware
All Optional Hardware must be tested except when the Optional Hardware is customer removable, and does not provide a unique function within the instance.
- Quantity of a function is not considered unique.
Example
A dual and a quad Ethernet adapter with all other capabilities being the same are considered to provide the same function and is clearly noted for use with another operating system in the specification.
- Notes must be in the positive tone (Example: "for use with…") and not the negative (Example: "not for use with…").] OR
- Marked to disclose any Service Level impacts as appropriate on the instance specifications and/or the instance support URL and on all materials using the Red Hat Certification marks in association with the Instance Type.
Example
If an Instance Type is available both with and without a SAS controller, and is also available with three functionally identical optional network cards, one of which is identified for use with Fedora only, the required testing would include the SAS controller and the two remaining optional network cards.
7.6. Non-OS features
Hardware features not offered by the operating system are not required to be tested if the remaining Instance Type continues to be fully functional. For example, IEEE 1394, a type of storage not currently supported in Red Hat Enterprise Linux, would not require testing. If, however, the Instance Type only had IEEE 1394 storage, it would not qualify for a Red Hat Enterprise Linux certification.
A Red Hat Knowledge Base Article may be added to the certification listing for clarity of Non-OS features.
7.7. Minimum test set
The Red Hat CCSP Instance Type certification encourages testing with all configurations including the maximum and minimum supported configurations. It is also recognized that resourcing these configurations can be difficult due to availability, cost, timing, and other constraints.
For these reasons we have defined a minimum requirements policy by hardware class in the Hardware-Feature-Requirements-by-Class section.
The table is designed to ensure an appropriate and reasonable testing effort to achieve certification.
The minimum testing requirements are not intended as product release criteria and it is expected that each partner conduct Red Hat Enterprise Linux and other Red Hat product interoperability and qualification testing in addition to certification testing.
7.8. Installation requirements for CCSP Instance
The installation may require testing via a number of mediums. Additionally, all boot devices must be tested to ensure a successful boot of RHEL.
Red Hat recommends combining boot and install testing where possible.
Example
Booting from the Red Hat Enterprise Linux installation media on a CD and performing a full installation fulfills the CD boot and installation testing requirements.
Kdump is a common feature for RHEL. Kdump utilizes the Linux kernel kexec feature to boot a kernel without a hardware reset in the event of a crash and capture the state of the previous kernel. This feature is enabled by default and must be tested to ensure this critical debug information can be captured properly. The kdump test will automatically be planned when the kdump service is enabled.
Kdump testing is required for all architectures and is to be conducted on both an integrated storage controller and an integrated network adapter. These requirements apply to all RHEL 7, RHEL 8 and RHEL 9 version certifications on the 64-bit Intel and AMD systems , and 64-bit IBM PowerPC architectures. Additionally, RHEL allows testing of Kdump on IBM System z architectures.
The CCSP Instance Type installation testing is only required on Instance Type where installation is available to and performed by customers.
