feat: add Rocky Linux support to state-OFED

[furlongm]

Rocky Linux is Red Hat Enterprise Linux compatible and uses the
same cert trust store and yum repo directory layout. Add rocky
entries to CertConfigPathMap and RepoConfigPathMap so state-OFED
can render the doca-driver DaemonSet on Rocky nodes.

Rocky has no subscription-manager equivalent so it is
intentionally omitted from SubscriptionPathMap; users provide
their own repo via NicClusterPolicy.spec.ofedDriver.repoConfig.

Fixes: #240
Signed-off-by: Marcus Furlong furlongm@gmail.com

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[greptile-apps]

Greptile Summary

This PR adds Rocky Linux support to state-OFED by reusing RHEL certificate-trust and yum-repository paths while intentionally omitting subscription-manager mounts.

• Adds Rocky entries to the certificate and repository path maps.
• Adds rendering coverage for Rocky with and without repository and certificate ConfigMaps.
• Verifies Rocky uses the expected RHEL-compatible mount destinations and receives no subscription mounts.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains; the new Rocky configuration test now supplies both repository and certificate ConfigMaps and verifies their rendered mount destinations.

Important Files Changed

Filename	Overview
pkg/state/state_ofed.go	Adds Rocky Linux mappings for the RHEL-compatible certificate trust store and yum repository directory.
pkg/state/state_ofed_test.go	Adds Rocky rendering tests that exercise both new path mappings and verify subscription mounts remain absent.

_{Reviews (2): Last reviewed commit: "feat: add Rocky Linux support to state-O..." | Re-trigger Greptile}

[greptile-apps]

Rocky path mappings remain untested

The Rocky test leaves RepoConfig and CertConfig unset, so it bypasses both newly added path mappings and would not detect an invalid repository or certificate mount destination.

Knowledge Base Used: NicClusterPolicy Reconcile Flow

[rollandf]

Hi @furlongm , is it a real use case? Do you have a cluster with Rocky OS that will need DOCA Ofed container?
Will you be able to test this on a cluster?

[furlongm]

Yes, real use case.

The current workaround for rocky nodes is to do the following on each node:

mkdir /etc/rhsm
mkdir /etc/pki/entitlement
touch /etc/yum.repos.d/redhat.repo

and then add NFRs to spoof rocky as rhel:

apiVersion: nfd.k8s-sigs.io/v1alpha1
kind: NodeFeatureRule
metadata:
  name: spoof-rocky-as-rhel
spec:
  rules:
    - name: spoof-rocky-as-rhel-on-mynode
      labels:
        "feature.node.kubernetes.io/system-os_release.ID": "rhel"
        "feature.node.kubernetes.io/system-os_release.VERSION_ID": "9.6"
        "feature.node.kubernetes.io/system-os_release.VERSION_ID.major": "9"
        "feature.node.kubernetes.io/system-os_release.VERSION_ID.minor": "6"
      matchFeatures:
        - feature: system.name
          matchExpressions:
            nodename: {op: In, value: [mynode]}

This PR removes the need for the workaround steps.

[rollandf]

@furlongm thanks for the response.
Note that NVIDIA is not currently publishing official DOCA OFED images for Rocky.
The tags of the DOCA OFED containers contains the OS of the host, e.g. nvcr.io/nvidia/mellanox/doca-driver:doca3.2.3-25.10-3.1.8.0-0-rhel9.6-amd64, so unless you plan to build these yourself for Rocky or maybe retag the RHEL and host them this PR is not enough.

[furlongm]

Would it be possible to get the images published for Rocky?

The GPU operator already publishes images for Rocky, e.g. https://catalog.ngc.nvidia.com/orgs/nvidia/-/containers/driver/580.173.02-rocky9

Seems like it would make sense to have the network operator publish Rocky images too?

Currently, retagging the RHEL images works correctly as Rocky is RHEL-compatible (or you can use the NFR workaround to spoof the OS name).

[rollandf]

LGTM

[rollandf]

Would it be possible to get the images published for Rocky?

The GPU operator already publishes images for Rocky, e.g. https://catalog.ngc.nvidia.com/orgs/nvidia/-/containers/driver/580.173.02-rocky9

Seems like it would make sense to have the network operator publish Rocky images too?

Currently, retagging the RHEL images works correctly as Rocky is RHEL-compatible (or you can use the NFR workaround to spoof the OS name).

We will raise this question with Product Manager.