[Bug]: Cannot use custom repoConfig together with RHEL host subscription repositories after #2391 #2817

Describe the bug

On RHEL nodes we use the GPU Operator with a custom driver.repoConfig
ConfigMap to provide additional package repositories required by the NVIDIA
driver installation.

At the same time, we rely on the RHEL subscription configuration from the
host for the standard RHEL BaseOS/AppStream repositories.

Before #2391, the driver pod received the RHEL host subscription mounts:

• /etc/pki/entitlement
• /etc/yum.repos.d/redhat.repo
• /etc/rhsm

With #2391, enabling repoConfig causes these host subscription mounts to be
skipped completely:

if cr.Spec.IsRepoConfigEnabled() && pool.osRelease == "rhel" {
    logger.Info("Skipping host subscription mounts because repoConfig is enabled", ...)
} else {
    pathToVolumeSource, err = getSubscriptionPathsToVolumeSources(pool.osRelease)
    ...
}

This makes repoConfig mutually exclusive with the RHEL subscription
repositories.

Expected behavior

repoConfig should allow adding custom repositories while still allowing the
driver container to use the RHEL subscription repositories from the host.

In our environment we need both:

Host RHEL subscription
  ├── BaseOS
  └── AppStream

Custom repoConfig
  └── additional repository (e.g. CUDA/internal repository)

The custom repository does not replace the RHEL repositories.

Actual behavior

As soon as driver.repoConfig is configured, the RHEL host subscription
mounts are omitted.

The driver container consequently cannot access packages that are only
available through the RHEL repositories.

For example, driver installation fails with:

dnf install -y --releasever=9 elfutils-libelf-devel.x86_64

No match for argument: elfutils-libelf-devel.x86_64
Error: Unable to find a match: elfutils-libelf-devel.x86_64
FATAL: failed to install elfutils-libel-devel.
RHEL entitlement may be improperly deployed.

The same package can be resolved successfully on the RHEL host using its
subscription repositories.

If repoConfig is removed, the Operator mounts the host RHEL subscription
configuration again and the RHEL repositories are available.

Why #2391 causes a regression for this use case

I understand that #2391 addresses air-gapped RHEL installations where
redhat.repo and/or RHSM paths might not exist and a custom repoConfig
completely replaces the distribution repositories.

However, repoConfig does not necessarily mean that the user wants to
replace the RHEL repositories.

There are two valid configurations:

1. Fully air-gapped:
   repoConfig replaces all package repositories.

2. Additional repositories:
   RHEL subscription repositories + repoConfig.

After #2391 only case 1 is possible.

Suggested solution

Do not automatically disable RHEL subscription mounts merely because
repoConfig is configured.

Alternatively, provide an explicit option, for example:

driver:
  repoConfig:
    configMapName: custom-repos
    disableSubscriptionMounts: false

This could default appropriately for backwards compatibility / air-gapped
installations.

Another possibility would be a separate option controlling host subscription
mounts:

driver:
  useHostSubscription: true

This would allow users to explicitly choose between:

repoConfig only

and:

repoConfig + host RHEL subscription

Environment

• OS: RHEL 9
• Kubernetes: RKE2
• Container runtime: containerd
• GPU Operator: v26.7.0
• Related PR: Updated Red Hat mounts for air-gapped clusters #2391
• Related issue: Driver init fails in air-gapped clusters due to hard-coded mount of Red Hat subscription repo config #1501