Chapter 5. Functional certification for OpenShift badges Certification badges extend the Red Hat OpenShift certification into specific functional areas or infrastructure services. A badge indicates that a certified product delivers capabilities that have been verified by Red Hat, such as conformance with Kubernetes Container Storage Interface (CSI) or Container Networking Interface (CNI) APIs. If your product delivers any of the capabilities described in this section, Red Hat encourages you to conduct additional tests. This helps you to identify your product accordingly on the Red Hat Ecosystem Catalog . 5.1. Container Network Interface (CNI) The CNI badge is a specialization within Red Hat OpenShift certification. It is available for networking products that integrate with OpenShift using a CNI plug-in . 5.1.1. Plug-in requirements The plug-in must conform to the CNI specification version 0.3.1 or later. You must manage the CNI plug-in through an Operator that meets the Operator certification requirements described in this document. To manage the updates to the CNI plug-in, the Operator must have the Seamless Upgrades capability and reflects this in the CSV. 5.1.2. OpenShift interoperability requirements In addition to the default requirements for functional verification , the OpenShift cluster that you use to verify the CNI functionality must have the Multus CNI plug-in enabled during all tests. All the components that are installed on the host must be tested and supported on the versions of Red Hat Enterprise Linux and Red Hat Enterprise Linux CoreOS. The CNI plug-in must support OpenShift Virtualization. Any unsupported or degraded features of the plug-in or OpenShift Virtualization when used in combination, must be indicated in your product documentation. As part of the CNI certification badge, the CNI plugin can be verified for compatibility with Red Hat OpenShift Service Mesh. 5.1.3. Lifecycle management requirements The plug-in must ensure minimal impact on upgrades for either major or minor plug-in releases. The plug-in upgrades should not require a full node reboot (whether major or minor) and must preserve existing connections during cluster upgrades. The plug-in must allow new connections during upgrades. If new or existing connection preservation is not possible, this must be documented along with detailed upgrade steps. For example, if a full cluster drain or node cordoning/drain is required. The plug-in documentation must show any difference in upgrade procedure between minor releases, bug fixes, or major updates. Certifications are specific to the OpenShift minor release tested. Partners are required to recertify their product on new minor OpenShift releases. 5.1.4. CNI test compliance The plug-in must pass the network tests of the OpenShift End-to-End Tests , based on the Kubernetes End-to-End Tests .These tests exercise the basic functions of the plug-in and show conformance to Kubernetes networking expectations. It is mandatory to complete the corresponding virtualization tests to validate the interoperability between the CNI plug-in and Red Hat OpenShift Virtualization. If you want to check the interoperability between the CNI plug-in and Red Hat OpenShift Service Mesh, complete the corresponding service mesh tests as part of the certification. Running the service mesh tests is optional. Additional resources For more information about performing the certification, see Workflow Guide . For more information about the capability level of Operators, with Seamless Upgrades, see Operator Framework documentation . 5.2. Container storage interface (CSI) The CSI badge is a specialization within Red Hat OpenShift Certification. It is available to the storage products that integrate with OpenShift using a CSI driver. 5.2.1. Driver requirements The CSI driver must implement version 1.0 or later of the CSI specification . The CSI driver must implement the Create and Delete volume capabilities. All other capabilities are optional but, if implemented and supported, they must be declared via a manifest file see ( example manifest file ) so they can be tested. Additional resources For more information about the CSI versions supported by a specific OpenShift version, see specific release documents. 5.2.2. Operator and sidecar requirements The CSI driver must be deployed and managed through an Operator that meets the Operator certification requirements described in this document. The requirements to use certified operands (containers) also apply to the driver's sidecar images. You should build and maintain their sidecar images so they can meet this criterion. You can select a sidecar image published and maintained by Red Hat, available as a part of OpenShift. If you do so, verify the interoperability of your CSI driver with the sidecars, as well as test and incorporate sidecar updates when available. 5.2.3. OpenShift interoperability requirements All components installed on the host must be tested and supported on the versions of Red Hat Enterprise Linux and Red Hat CoreOS, used by the OpenShift release targeted for certification. The CSI driver should support the storage features listed in the OpenShift Virtualization storage feature matrix , so users can take full advantage of platform services for virtual machines. The CSI product documentation must indicate if any of these features are not supported by the driver. 5.2.4. CSI test compliance The plugin must complete the CSI tests of the OpenShift End-to-End Tests , based on the Kubernetes End-to-End Tests . Execute the tests for each of the storage protocols supported (such as iSCSI, NFS, FC) and must match the declared capabilities. Additional resources For more information about performing the certification, see Workflow Guide .

Commands: