feat(recipe): add NFD as standalone shared component

[ArangoGutierrez]

Summary

• Extract Node Feature Discovery from gpu-operator's sub-chart into a standalone shared component
• Both gpu-operator and network-operator now depend on this shared NFD instance via dependencyRefs
• Network-operator gains NIC labeling via NodeFeatureRule CR (deployNodeFeatureRules: true)
• NFD becomes a base-level component — every recipe inherits it automatically

Changes

Area	Change
recipes/registry.yaml	Add nfd component with helm config, healthCheck, nodeScheduling; remove NFD paths from gpu-operator
recipes/components/nfd/values.yaml	New file — Master + Worker + GC enabled, TopologyUpdater off
recipes/overlays/base.yaml	Add nfd componentRef before cert-manager
recipes/overlays/*.yaml (12 files)	Add nfd to gpu-operator/network-operator dependencyRefs
recipes/components/gpu-operator/values.yaml	nfd.enabled: false (disable sub-chart)
recipes/components/network-operator/values.yaml	nfd.deployNodeFeatureRules: true
recipes/overlays/kind.yaml	Remove nfd.enabled: true override (no longer needed)
recipes/checks/nfd/health-check.yaml	Chainsaw health check: Master Deployment + Worker DaemonSet + pod phases

Design

Follows the existing cert-manager pattern — purely declarative, no Go code changes. NFD deploys to node-feature-discovery namespace. Worker DaemonSet runs on all nodes (excluded from accelerated nodeSelector) so it discovers hardware features everywhere.

Install order: nfd → cert-manager → gpu-operator / network-operator → nvsentinel, etc.

Verification

• make test — all packages pass with race detector (72.5% coverage)
• make lint-go — 0 issues
• make build — builds successfully
• Recipe resolution: NFD appears in all resolved recipes
• aicr query confirms gpu-operator.values.nfd.enabled: false
• aicr query confirms network-operator.values.nfd.deployNodeFeatureRules: true
• gpu-operator and network-operator both have nfd in dependencyRefs

Related

Track B of NFD Adoption (Track A — NFD snapshot enrichment — completed 2026-04-08)

[mchmarny]

Clean, declarative PR that follows the cert-manager shared-component pattern. No Go code changes needed — the registry + overlay system handles everything. Good separation of concerns.

Issues to address:

1. Missing overlays — rtx-pro-6000-lke-inference.yaml and rtx-pro-6000-lke-training.yaml re-declare gpu-operator's dependencyRefs without nfd. If overlays replace rather than merge, gpu-operator has no ordering dependency on nfd in those recipes.

2. Health check missing GC — The values enable gc.enable: true and the registry configures GC scheduling paths, but the health check only validates Master and Worker. The old gpu-operator assertions checked GC — this is a coverage regression.

Minor:

• PR description says "nfd → cert-manager" install order, but the actual computed deployment order (visible in test assertions) places nfd after cert-manager. Not a bug (they're independent), but the description is misleading.

Looks good:

• Worker excluded from accelerated nodeSelectorPaths so it runs everywhere — correct and well-commented
• nfd.enabled: false in gpu-operator + deployNodeFeatureRules: true in network-operator is the right combination
• kind overlay cleanup (removing nfd.enabled: true override) is correct
• Old NFD assertions removed from assert-gpu-operator.yaml since they'd check the wrong namespace now
• Registry entry is well-structured with proper nodeScheduling paths

[mchmarny]

Two overlays that re-declare gpu-operator's dependencyRefs were not updated to include nfd:

• recipes/overlays/rtx-pro-6000-lke-inference.yaml — gpu-operator dependencyRefs: [cert-manager, kube-prometheus-stack]
• recipes/overlays/rtx-pro-6000-lke-training.yaml — gpu-operator dependencyRefs: [cert-manager, kube-prometheus-stack]

If leaf overlays replace (not merge) the base dependencyRefs, gpu-operator would not depend on nfd in RTX PRO 6000 LKE recipes. NFD still deploys as a standalone component, but without the dependency edge there's no ordering guarantee — gpu-operator could start before nfd is ready.

[mchmarny]

The values.yaml enables the GC component (gc.enable: true) and the registry defines gc.nodeSelector/gc.tolerations paths, but this health check doesn't validate the GC Deployment. The old gpu-operator assertions (assert-gpu-operator.yaml) did check node-feature-discovery-gc.

Consider adding a step:

- name: validate-gc-deployment
  try:
    - assert:
        resource:
          apiVersion: apps/v1
          kind: Deployment
          metadata:
            name: node-feature-discovery-gc
            namespace: node-feature-discovery
          status:
            (conditions[?type == 'Available']):
              - status: "True"

[mchmarny]

Good call excluding worker from accelerated.nodeSelectorPaths — workers need to run on every node for hardware discovery. The comment is clear and sufficient.

[mchmarny]

The old values had node-feature-discovery.fullnameOverride: node-feature-discovery under the sub-chart key. The new values use nfd.enabled: false — which is the correct top-level key for the gpu-operator chart's NFD toggle. Clean.

One thing to verify: does the gpu-operator chart version used in current recipes support nfd.enabled: false as the disable mechanism? Older gpu-operator chart versions used the node-feature-discovery sub-chart key directly. If any overlay pins an older gpu-operator chart version, the sub-chart might still deploy.

[mchmarny]

Version is documented as v0.18.3 in the comment and pinned in base.yaml. The values here are minimal and sensible defaults. Topology updater disabled by default with a note about overlay overrides is a good approach.

[mchmarny]

This enables deployNodeFeatureRules while keeping nfd.enabled: false. That's the correct combination — network-operator uses the external standalone NFD to create NodeFeatureRule CRs for NIC labeling without deploying its own NFD instance.

[mchmarny]

The kind overlay removed nfd.enabled: true from gpu-operator overrides (no longer needed since NFD is standalone). But it also needs nfd in network-operator's dependencyRefs at line 194 — which is included in this PR. Looks correct.

[mchmarny]

The PR description states the install order is "nfd → cert-manager → gpu-operator", but the deployment order here shows nfd after cert-manager and kube-prometheus-stack. This isn't a bug — nfd and cert-manager are independent in the dependency graph, so their relative order is determined by the topological sort tiebreaker. But updating the PR description to match the actual computed order would avoid confusion.