[gpu-operator] Introduce GPU-operator - #765

Reviewing files that changed from the base of the PR and between 49b5b51 and 78af5e2.

• packages/system/gpu-operator/charts/gpu-operator/Chart.lock is excluded by !**/*.lock

• packages/core/platform/bundles/paas-full.yaml (1 hunks)
• packages/system/gpu-operator/Chart.yaml (1 hunks)
• packages/system/gpu-operator/Makefile (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/.helmignore (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/Chart.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/.helmignore (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/Chart.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/README.md (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/crds/nfd-api-crds.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/_helpers.tpl (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/clusterrole.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/clusterrolebinding.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/master.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/nfd-gc.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/nfd-master-conf.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/nfd-topologyupdater-conf.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/nfd-worker-conf.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/post-delete-job.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/prometheus.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/role.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/rolebinding.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/serviceaccount.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/topologyupdater-crds.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/topologyupdater.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/worker.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/values.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/crds/nvidia.com_nvidiadrivers.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/_helpers.tpl (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/cleanup_crd.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/clusterpolicy.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/clusterrole.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/clusterrolebinding.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/dcgm_exporter_config.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/mig_config.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/nodefeaturerules.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/nvidiadriver.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/operator.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/plugin_config.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/readonlyfs_scc.openshift.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/role.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/rolebinding.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/serviceaccount.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/upgrade_crd.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/values.yaml (1 hunks)
• packages/system/gpu-operator/values-talos.yaml (1 hunks)
• packages/system/gpu-operator/values.yaml (1 hunks)
• packages/system/kubevirt/templates/kubevirt-cr.yaml (1 hunks)

packages/system/gpu-operator/values.yaml (1)

1-1: New GPU Operator Configuration Entry:
The addition of an empty gpu-operator: {} block serves as a useful placeholder for future GPU operator configuration options. Ensure that any necessary parameters can be added to this section later if needed.

packages/system/kubevirt/templates/kubevirt-cr.yaml (1)

12-18: Addition of the GPU Feature Gate:
The GPU feature gate is added to the developerConfiguration.featureGates list. This enables GPU-related functionalities within the KubeVirt deployment. Verify that the rest of your system components properly support this new gate.

packages/system/gpu-operator/Chart.yaml (1)

1-4: Helm Chart Metadata Verification:
The Chart.yaml for the GPU operator is correctly set up with apiVersion: v2, the chart’s name, and a placeholder version. Confirm that your build process automatically updates the version before release.

packages/core/platform/bundles/paas-full.yaml (1)

156-166: GPU-Operator Release Entry — Correct Integration with Dependencies and Configuration

The new GPU-operator release entry is clearly defined: it sets the proper releaseName, references the cozy-gpu-operator chart, and includes the expected namespace along with the dependencies on cilium and kubeovn. The use of privileged: true along with optional: true seems appropriate for an operator that might not be deployed on every cluster by default.

Please verify that:

• The namespace cozy-gpu-operator exists or is created elsewhere in your deployment manifests.
• The referenced values files (values.yaml and values-talos.yaml) align with the operator’s required configuration.

Overall, this looks well-integrated into the releases bundle.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/nfd-worker-conf.yaml (1)

1-13: Review of NFD Worker ConfigMap Template

The template correctly uses a conditional block to create the ConfigMap only when .Values.worker.enable is true. The use of Helm functions (such as include, toYaml, and nindent) is consistent with best practices to ensure proper formatting of the generated YAML. Note that the YAMLlint error on line 1 (regarding the leading dash in {{- if ... }}) is a known false positive caused by Helm templating syntax.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/nfd-topologyupdater-conf.yaml (1)

1-13: Review of NFD Topology Updater ConfigMap Template

This template conditionally creates a ConfigMap for the topology updater based on .Values.topologyUpdater.enable. The metadata uses Helm templating functions to inject dynamic names, namespaces, and labels. Like in the previous file, the YAMLlint error at line 1 is likely a false positive due to the {{- if ... }} syntax.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/gpu-operator/charts/gpu-operator/templates/rolebinding.yaml (1)

1-16: Review of RoleBinding Template for GPU Operator

This RoleBinding template defines the necessary binding between the gpu-operator ServiceAccount and its corresponding Role. The metadata is dynamically generated using Helm templating, which is a good practice for consistency in deployments. However, YAMLlint reports an indentation warning on line 7 (expecting 2 spaces instead of 4) and a syntax warning on line 6 (related to the use of {{- include ... }}). These issues are common false positives when linting templated YAML. It is recommended to run helm lint to verify that the rendered YAML is correctly indented and valid.

🧰 Tools

🪛 YAMLlint (1.35.1)

[warning] 7-7: wrong indentation: expected 2 but found 4

(indentation)

---

[error] 6-6: syntax error: expected the node content, but found '-'

(syntax)

packages/system/gpu-operator/charts/gpu-operator/templates/clusterrolebinding.yaml (1)

1-16: Review of ClusterRoleBinding Template for GPU Operator

Similar to the RoleBinding, this ClusterRoleBinding template is structured to grant cluster-level permissions by binding the gpu-operator ServiceAccount to a ClusterRole. The dynamic construction of labels and namespace via Helm templating is properly implemented. YAMLlint reports an indentation warning on line 7 and a syntax error on line 6; these are likely false positives due to the templating syntax. Please ensure that the final rendered output passes helm lint.

🧰 Tools

🪛 YAMLlint (1.35.1)

[warning] 7-7: wrong indentation: expected 2 but found 4

(indentation)

---

[error] 6-6: syntax error: expected the node content, but found '-'

(syntax)

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/prometheus.yaml (1)

1-27: Review of PodMonitor Template for Prometheus Monitoring

This template provisions a PodMonitor resource to enable Prometheus monitoring for the Node Feature Discovery component. The conditional inclusion based on .Values.prometheus.enable and the dynamic metadata using Helm functions (including merging additional labels via with/toYaml) are well implemented. YAMLlint reports several issues (e.g., a syntax error on line 1 and indentation warnings on lines 10–11, 21, and 24). These errors can be safely ignored if the rendered YAML (verified via helm lint) is valid.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

[warning] 10-10: wrong indentation: expected 2 but found 4

(indentation)

---

[warning] 11-11: wrong indentation: expected 2 but found 4

(indentation)

---

[warning] 21-21: wrong indentation: expected 6 but found 4

(indentation)

---

[warning] 24-24: wrong indentation: expected 6 but found 4

(indentation)

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/serviceaccount.yaml (4)

1-13: Master ServiceAccount Block – Looks Good:
This block conditionally creates a ServiceAccount for the master component. The metadata (name, namespace, labels, and optional annotations) is dynamically populated using helper templates. The logic is clear and correct.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

15-28: TopologyUpdater ServiceAccount Block – Valid:
The conditional and templating for creating the ServiceAccount for the topology updater feature is well implemented.

---

30-43: GC ServiceAccount Block – Valid:
The block that creates the ServiceAccount for the garbage collection component is implemented properly with consistent use of conditionals and helper templates.

---

45-58: Worker ServiceAccount Block – Good to Go:
The Worker ServiceAccount is conditionally generated using dynamic helper functions, and the structure follows your project's patterns.

packages/system/gpu-operator/charts/gpu-operator/templates/dcgm_exporter_config.yaml (1)

1-15: DCGM Exporter ConfigMap Template – Reviewed:
This template correctly nests two conditionals: first checking for the existence of a DCGM exporter configuration, then verifying that it should be created and that its data is not empty. The use of toYaml and nindent ensures proper formatting. Note that YAMLlint may flag line 1 due to templating syntax; this is a known false positive.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/nfd-master-conf.yaml (1)

1-13: NFD Master ConfigMap Template – Looks Solid:
The template conditionally creates a ConfigMap for the Node Feature Discovery master configuration. The metadata (name, namespace, and labels) and the data block (using a block scalar with |-) are correctly structured. Ensure that the output from toYaml meets your formatting expectations. YAMLlint warnings on templated lines are expected.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/gpu-operator/charts/gpu-operator/templates/mig_config.yaml (1)

1-11: MIG ConfigMap Template – Implementation Verified:
This template conditionally creates a ConfigMap if migManager.config.create is true and its data is non-empty. The usage of toYaml with nindent for the data block is appropriate. Similar YAMLlint warnings are expected due to Helm templating syntax and can be safely ignored if the rendered output is correct.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/gpu-operator/charts/gpu-operator/templates/nodefeaturerules.yaml (1)

1-1: Template Syntax Caution:
The templating directive on line 1

{{- if .Values.nfd.nodefeaturerules }}

is triggering a YAML syntax error according to static analysis. Confirm that this syntax is acceptable in your Helm chart context and adjust if your YAML linter requires a slightly different format.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/Chart.yaml (1)

1-15: Helm Chart Metadata Validation:
The metadata in this Chart.yaml file appears correctly structured, including the API version, application version, description, and other required fields. Just ensure that the version: 0.17.2 remains in sync with the upstream Node Feature Discovery chart if updates occur.

packages/system/gpu-operator/charts/gpu-operator/templates/cleanup_crd.yaml (1)

1-51:

Details

✅ Verification successful

Cleanup CRD Job Template – YAML Lint and Indentation Issues

The Helm template for the cleanup job is well structured and uses conditional inclusion based on .Values.operator.cleanupCRD. However, YAMLlint reported a syntax error at the very beginning (line 1) and an indentation warning later in the file (notably around line 20). These issues typically arise when raw Helm template directives (e.g. {{- if … }}) are processed by linters that expect pure YAML. Please ensure your linter is configured to handle Helm templating or verify the rendered output using helm template.

---

Helm Templating Linter Configuration – No Code Changes Required

The YAML lint errors are false positives caused by linting raw Helm templating directives rather than the rendered YAML. Please ensure your YAML linter is configured to handle Helm templates or verify the output with helm template (which should show valid YAML).

• File: packages/system/gpu-operator/charts/gpu-operator/templates/cleanup_crd.yaml
• Notes:
  • The syntax error at line 1 and the indentation warning (around line 20) are expected when a linter processes Helm directives.
  • No changes are needed in the template itself if the rendered output is correct.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

[warning] 20-20: wrong indentation: expected 6 but found 8

(indentation)

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/master.yaml (1)

1-171:

Details

❓ Verification inconclusive

NFD Master Deployment Template – Handling of Templating Directives

This Deployment template for the Node Feature Discovery (NFD) master is thorough and contains many customizable parameters via Helm values. Static analysis tools are flagging a syntax error at the start (line 1) and an indentation warning on line 9. These warnings likely result from the Helm templating directives (e.g. {{- if .Values.master.enable }}) that may confuse linters expecting standard YAML. It is recommended to either adjust the linter configuration to process rendered output or confirm the final YAML using helm template.

---

Review: Helm Templating Warnings in NFD Master Deployment Template

The static analysis warnings (syntax error at line 1 and indentation warning at line 9) are expected due to Helm’s templating directives. These lines are not errors in the final rendered YAML. To proceed safely:

• Confirm the rendered output using helm template to ensure valid YAML.
• Update your linter configuration (or exclude these files) so that Helm directives are not flagged as errors.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

[warning] 9-9: wrong indentation: expected 2 but found 4

(indentation)

packages/system/gpu-operator/charts/gpu-operator/templates/operator.yaml (1)

1-100: Operator Deployment Template – Helm Templating and Linter Considerations

The GPU operator deployment is clearly defined with proper separation of concerns (metadata, spec, container configuration, probes, etc.). However, static analysis reported an indentation warning and a syntax error at the templating directive on line 6 (e.g. {{- include "gpu-operator.labels" . | nindent 4 }}). These issues are typical when linters are applied to Helm templates. Please verify that your linter is configured to process Helm templates or review the rendered manifest using helm template to ensure the final output is valid.

🧰 Tools

🪛 YAMLlint (1.35.1)

[warning] 7-7: wrong indentation: expected 2 but found 4

(indentation)

---

[error] 6-6: syntax error: expected the node content, but found '-'

(syntax)

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/role.yaml (1)

1-26: NFD Worker Role Template – Handling of Helm Templating Directives

The Role resource correctly grants RBAC permissions needed for Node Feature Discovery, with proper rules for both the nfd.k8s-sigs.io API group and core pods access. Static analysis flags a syntax error on line 1 due to the Helm templating directive ({{- if and .Values.worker.enable .Values.worker.rbac.create }}). This is a known behavior when linters parse raw Helm templates. You can safely ignore this warning if the rendered output is correct.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/values.yaml (4)

9-12: Override Settings for Name, Fullname, and Namespace
The override values are set to empty strings, which is standard for allowing users to override defaults. This approach looks good.

---

13-17: Feature Gates and Priority Class
The featureGates mapping and priorityClassName field are straightforward. Make sure that any future additions to feature gates are well documented so that users know what toggles are available.

---

93-102: ServiceAccount Configuration
The serviceAccount section properly indicates that a new account is created by default if none is provided. This enhanced usability is appreciated.

---

109-120: Resource and Revision Configuration
The resource limits and requests for memory and CPU are clearly defined. The revision history and RBAC configurations are minimal but sufficient for a basic deployment.

packages/system/gpu-operator/charts/gpu-operator/templates/nvidiadriver.yaml (6)

1-4: Helm Templating and Conditional Rendering for NVIDIADriver
The file begins with a conditional check using Helm templating (line 1). The configuration for the NVIDIADriver resource and its metadata is clear and well structured.

• Note: The YAML lint error complaining about a syntax issue at line 1 is a known false positive caused by the Helm templating syntax (“{{- if … }}”). This can safely be ignored.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

13-18: Annotations and Labels Conditional Inclusion
The use of conditional blocks to include annotations (lines 13–15) and labels (lines 16–18) using the toYaml helper with proper indentation (nindent) is a good practice and improves maintainability.

---

19-24: Node Selector and ImagePullSecrets Handling
The template conditionally adds nodeSelector and imagePullSecrets based on provided values. This flexible design ensures that resource configurations remain concise while still supporting advanced customization.

---

37-45: Manager, Startup, Liveness, and Readiness Probes
The subsequent conditional blocks for manager settings, probes, and RDMA settings ensure that the CRD is comprehensive and adapts to the user’s configuration needs. Overall, the logic is clear and follows best practices.

---

73-79: GDS Configuration Block
The GDS settings (lines 73–79) are conditionally included and structured similarly to other sections. This consistency simplifies future maintenance and upgrades.

---

95-117: GDRCopy Configuration Block
The GDRCopy block mirrors the structure of the GDS block and is similarly well implemented. All fields are properly templated.

packages/system/gpu-operator/charts/gpu-operator/templates/upgrade_crd.yaml (6)

1-1: Helm Conditional for Upgrade CRD Hook
The file begins with a conditional check on .Values.operator.upgradeCRD.

• Note: YAML lint may flag a syntax error at line 1 because of the leading Helm directive. This is another common false positive; no action is required.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

2-11: ServiceAccount Resource for Upgrade Hook
The ServiceAccount is defined with pre-upgrade hook annotations. The hook deletion policy and weight are set correctly to ensure proper lifecycle management during upgrades.

---

12-32: ClusterRole Resource Definition
The ClusterRole includes the expected permissions (create, get, list, watch, patch, update) for managing CRDs. The hook annotations are consistently applied.

---

33-49: ClusterRoleBinding Resource
The ClusterRoleBinding binds the ServiceAccount to the ClusterRole with proper annotations. The usage of the Helm templating for the namespace ({{ .Release.Namespace }}) is correct.

---

50-59: Job Definition for CRD Upgrade
The Job is defined as a pre-upgrade hook with clear metadata and labels. The container command (lines 85–93) applies the required CRD YAML files using kubectl apply.

• Recommendation: Ensure that the inline shell command logic (with semicolon separation) handles errors gracefully and that the conditional block for NFD API CRDs (lines 91–93) works as intended.

---

81-96: Job Container and Restart Policy
The container specification (lines 81–93) and the restart policy set to OnFailure are appropriate for a one-off upgrade job.

packages/system/gpu-operator/charts/gpu-operator/values.yaml (13)

1-4: File Header and Documentation Comments
The headers and comments provide good context for users about the purpose of the file and how variables are used in the templates.

---

5-12: Platform and NFD Configuration
The platform configuration (line 5–7) and the NFD section (lines 8–10) are straightforward. Enabling NFD here makes sense, and the boolean flags are clearly documented.

---

15-22: PSA, CDI, and Sandbox Workloads Configuration
These sections (lines 12–22) set reasonable defaults. The naming and inline comments are clear.

---

52-60: Validator Configuration
The validator settings are concise and follow best practices.

---

67-95: Operator Configuration Block
This section (lines 67–95) sets the core operator parameters including repository, image, pull policy, runtime class, and upgrade options. The inclusion of fields such as cleanupCRD and upgradeCRD is useful.

• Recommendation: Verify that the runtimeClass value (nvidia) is valid in your deployment environments. Additionally, ensure that any changes to these fields are reflected in downstream documentation and tests.

---

129-150: Driver Configuration
The driver block (lines 129–150) is comprehensive. It specifies CRD options, kernel module type, repository, and image version.

• Note: The deprecation note regarding useOpenKernelModules (line 141) is helpful.

---

152-161: RDMA Configuration
The RDMA settings are minimal yet sufficient. This section prepares for future enhancements if RDMA support is enabled.

---

162-194: Upgrade Policy for Driver
The upgradePolicy section defines parameters like auto-upgrade, parallel upgrades, and pod deletion options.

• Recommendation: Consider quoting percentage values (e.g. maxUnavailable: "25%") to ensure YAML parsers do not misinterpret these as expressions.

---

194-214: Manager Configuration
The manager configuration is detailed and includes environment variables for GPU pod eviction and auto-drain. The inline commentary helps clarify version constraints.

---

233-242: Toolkit and Device Plugin Configurations
Both sections (lines 233–242 for toolkit and 244–265 for devicePlugin) are straightforward and use standard conventions.

---

301-310: DCGM and DCGM Exporter Configurations
The settings for DCGM (lines 301–308) and DCGM Exporter (lines 312–332) are appropriately specified.

---

435-444: GDS and GDRCopy Configurations
The GDS (lines 435–444) and GDRCopy (lines 445–454) sections mirror each other in style and consistency.

---

559-607: Node-Feature-Discovery and Related Configurations
The final section configuring Node Feature Discovery (lines 559 onward) is thorough. It provides separate configurations for the master and worker components, including service account settings, tolerations, and extra labels.

• Suggestion: Ensure that any list formats (such as for sources under worker configurations) adhere strictly to YAML formatting to avoid runtime parsing errors.

packages/system/gpu-operator/charts/gpu-operator/templates/readonlyfs_scc.openshift.yaml (5)

1-1: Helm Templating in SCC Definition
The conditional inclusion based on the OpenShift platform is correct. Note that YAML lint may report a syntax error on line 1 due to the Helm templating directive. This false positive can be safely ignored.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

2-8: SCC Metadata and Labels
The metadata section (lines 2–8) correctly assigns API version, kind, and leverages templating for labels.

---

13-20: SCC Spec Fields and Security Settings
The SCC spec includes fields that restrict host access and privileges (lines 13–20). These settings align with securing a read-only filesystem environment.

---

21-24: Capabilities and FSGroup Settings
The empty lists for allowed capabilities and default additions, along with an FSGroup strategy, are appropriate.

---

25-33: User and Group Configurations
The groups and runAsUser settings (lines 25–33) are defined correctly.

packages/system/gpu-operator/charts/gpu-operator/Chart.yaml (1)

1-24: Chart.yaml: Configuration and Dependency Definitions

The file cleanly defines the Helm chart metadata including the API version, app version, dependencies (with a conditional on nfd.enabled), and additional metadata such as description, homepage, icon, and keywords.
Consider verifying that the dependency’s version (v0.17.2) remains compatible with your cluster’s requirements and any recent security advisories.

packages/system/gpu-operator/charts/gpu-operator/templates/clusterpolicy.yaml (11)

1-13: Metadata and Conditional Annotations

The metadata section uses Helm templating effectively to include labels and conditionally add annotations (for CRD cleanup via pre-delete hook). Ensure that the value referenced (e.g. .Values.operator.cleanupCRD) is defined in your values files.

🧰 Tools

🪛 YAMLlint (1.35.1)

[warning] 7-7: wrong indentation: expected 2 but found 4

(indentation)

---

[error] 6-6: syntax error: expected the node content, but found '-'

(syntax)

---

14-17: HostPaths Configuration

The host paths for rootFS and driverInstallDir are clearly specified. Double-check that the provided values correctly reflect your cluster’s filesystem layout.

---

18-42: Operator Settings Templating

The operator section flexibly includes settings such as runtimeClass, defaultGPUMode, and an optional initContainer block via conditional templating. This design provides great flexibility. Verify that missing values are handled gracefully when these parameters are not defined.

---

43-45: Optional OCP Driver Toolkit Setting

This conditional block correctly injects the use_ocp_driver_toolkit flag when defined. Ensure that the documentation and default values in your values file align with its intended usage.

---

46-64: Daemonsets Configuration

The daemonsets section appropriately includes templated labels, optional annotations, tolerations, and update strategies. It would be beneficial to verify that the runtime and update behaviors match your operator’s upgrade policies.

---

65-93: Validator Configuration Parameters

The validator block is comprehensive and supports conditional configuration for repository, image, version, pull policies, secrets, resources, environment variables, and arguments. Consider adding inline documentation (or comments in your values file) to explain the impact of each parameter for future maintainability.

---

131-134: MIG Strategy Configuration

A straightforward, conditionally included block for configuring the MIG strategy.

---

135-139: PSA and CDI Settings

The PSA and CDI sections correctly reflect simple enablement flags and default values. Confirm that .Values.cdi.default is provided with an appropriate default.

---

212-234: Driver Upgrade Policy Configuration

The upgradePolicy section is very detailed—it covers auto-upgrade flags, parallel upgrade limits, unavailable limits, wait for completion, pod deletion, and drain configurations. Verify that these defaults lead to expected and safe upgrade behaviors.

---

235-245: vgpuManager Settings

The vgpuManager section is conditionally included and uses templating effectively. Just ensure that the default values maintain security and functionality.

---

140-169:

Details

❓ Verification inconclusive

Driver Configuration Block

This segment details the driver settings including repository, image, version, pull policies, probes, and sub-manager configurations. Given the block’s complexity, ensure comprehensive testing with various value inputs and consider modularizing this block into helper templates to improve readability.

---

Driver Configuration Block Refactoring & Verification

The driver configuration block (lines 140–169 in packages/system/gpu-operator/charts/gpu-operator/templates/clusterpolicy.yaml) is functionally correct and clearly renders multiple conditional settings. However, given its complexity, consider these improvements for future maintainability and clarity:

• Modularization: Evaluate breaking out individual subsections (such as repository, image, version, pull policy, and probes) into helper templates. This would simplify the main template and ease future modifications.
• Comprehensive Testing: Test the template with a variety of value inputs—including cases where some fields are omitted—to ensure the generated YAML remains valid under all conditions.

Please review and verify these suggestions in context with the rest of your chart configuration.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/nfd-gc.yaml (7)

1-1: YAML Syntax Warning on the Conditional Statement

The file begins with {{- if and .Values.gc.enable -}} on line 1. Static analysis indicates this may trigger a syntax error because the block starts with a hyphen. Verify that the templating syntax is supported by your Helm version and does not break downstream YAML parsers.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

2-10: Deployment Metadata Configuration

The metadata block—defining the deployment name, namespace, and labels—is well structured using Helm templating. Confirm that the helper templates (e.g. "node-feature-discovery.fullname") render the expected values.

---

11-20: Deployment Selector and Template Labels

Both the deployment selector and pod template labels merge templated values with static keys (such as role: gc). Ensure that these labels are consistent to facilitate correct pod selection by the deployment controller.

---

21-30: Pod Template Security and Service Account Settings

The pod spec correctly assigns a service account, DNS policy, (and optionally) priority class and image pull secrets. Double-check that the securityContext provided via Helm is complete and that sensitive settings are not omitted.

---

31-40: Container Configuration and Command Arguments

The container named gc is defined with an image reference, pull policy, and environment variable (using a field reference for the node name). The conditional inclusion of extra commands (e.g. -gc-interval) is handled appropriately.

---

41-48: Container Resources and Port Configuration

The resources and the metrics port (defaulting to 8081 if not provided) are correctly templated. Ensure that the resource limits, once substituted, meet your operational requirements.

---

49-52: NodeSelector, Affinity, and Tolerations

The deployment supports external scheduling configuration through nodeSelector, affinity, and tolerations. Verify these are rendered in the final YAML as expected.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/crds/nfd-api-crds.yaml (4)

1-8: NodeFeature CRD Definition

The Custom Resource Definition for NodeFeature is well-defined with a detailed OpenAPI v3 schema. It clearly specifies properties for attributes, flags, and instances.

---

9-121: Detailed Schema for NodeFeature

The schema provided for NodeFeature is comprehensive. Verify that the nested object definitions (such as those for attributes and instances) meet your data expectations and that any future changes to the feature discovery mechanism will remain compatible.

---

124-139: NodeFeatureGroup CRD Definition

The CRD for NodeFeatureGroup is structured appropriately. The use of a short name (e.g. nfg) improves usability. Ensure that the schema definitions correctly enforce the intended grouping rules.

---

395-412: NodeFeatureRule CRD Definition

The CRD for NodeFeatureRule defines a cluster-scoped resource with comprehensive schema details for node customization rules. Confirm that all enumerated operator values (such as In, NotIn, Exists, etc.) accurately reflect your rule processing logic.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/post-delete-job.yaml (1)

4-4:

Details

✅ Verification successful

ServiceAccount Name Syntax Issue

Static analysis reports a syntax error on line 4 (related to the ServiceAccount name). Please verify that the templated expression in
    name: {{ include "node-feature-discovery.fullname" . }}-prune
is correctly terminated and does not include extraneous characters that may confuse YAML parsers.

---

Helm Template Syntax Verified – No Changes Required

After verifying the templated expression, it appears that the syntax for
    name: {{ include "node-feature-discovery.fullname" . }}-prune
is valid. The closing mustache (}}) is correctly placed, and the concatenation with -prune is proper for Helm rendering. The static analysis warning appears to be a false positive.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 4-4: syntax error: expected , but found ''

(syntax)

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/topologyupdater.yaml (7)

1-1: Helm Template Conditional & YAMLlint False Positive
Line 1 starts with a Helm templating conditional ({{- if .Values.topologyUpdater.enable -}}). Note that YAML lint tools may report a syntax error here (“expected the node content, but found '-'”) even though this is valid in a Helm template.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

2-13: DaemonSet Metadata and Dynamic Naming
The metadata section is well structured. It uses helper templates for the name, namespace, and labels (e.g. using "node-feature-discovery.fullname" and "node-feature-discovery.labels"), ensuring consistency. The conditional block for annotations via .Values.topologyUpdater.daemonsetAnnotations adds flexibility.

---

14-30: DaemonSet Spec & Pod Template Identifiers
The DaemonSet specification and pod template metadata (including the selector and labels) are correctly set up. The inclusion of a checksum annotation for configuration (line 26) is a good practice for triggering pod rollouts when configMaps change.

---

30-39: Pod Specification: Service Account, DNS Policy, & Image Pull Secrets
The pod spec correctly sets the serviceAccountName and dnsPolicy. The optional inclusion of priorityClassName and the image pull secrets (using the toYaml helper) is implemented cleanly.

---

43-93: Container Configuration – Topology-Updater
The container named topology-updater is defined with dynamic image references and pull policy. Both liveness and readiness probes use gRPC on a configurable health port, and environment variables (e.g. NODE_NAME and NODE_ADDRESS) are systematically injected. The conditional args (lines 96–105) for sleep interval and namespace watching are clear and sensible.

---

121-139: Volume Mounts & Host Path Configuration
The volume mounts are carefully defined for resources like the kubelet podresources socket, host system files, and configuration via a ConfigMap. The conditional mount for the kubelet config and state files ensures that only available paths are mounted. Verify that the host paths (e.g. /host-var/lib/kubelet-podresources/kubelet.sock) exist as expected in your target nodes.

---

144-189: Resource & Scheduling Settings
The lower section (lines 144–189) handles resource requests, security context, node selector, affinity, and tolerations. This provides robust scheduling flexibility. Overall, the template aligns well with Helm best practices for deploying a DaemonSet.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/topologyupdater-crds.yaml (4)

1-1: Helm Template Conditional for CRD Creation
The CRD document is wrapped in a conditional that checks both .Values.topologyUpdater.enable and .Values.topologyUpdater.createCRDs. This ensures that the CRD is only created when intended. Like other Helm templates, initial templating syntax might trigger YAML lint warnings, which can be safely ignored.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

2-9: CRD Metadata and Basic Structure
The metadata (lines 2–9) correctly sets the API version, kind, and includes important annotations (e.g. the API approval and controller-gen version). The CRD name (noderesourcetopologies.topology.node.k8s.io) is also properly defined.

---

139-272: v1alpha2 Version: Updated Schema and Deprecations
The v1alpha2 version refines the schema by deprecating the topologyPolicies field and adding top-level attributes. This evolution aligns with Kubernetes’ API versioning practices. Confirm that users are aware of these schema changes as they migrate.

---

278-279: Closing the Helm Block
The file correctly ends the templating block. No issues are apparent here.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/worker.yaml (13)

1-1: Helm Template Conditional for Worker DaemonSet
The worker DaemonSet is conditionally enabled by .Values.worker.enable. Similar to other Helm templates, the templating syntax at the file start might trigger linting warnings, which are expected.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

2-7: Worker DaemonSet Metadata
The metadata section (lines 2–7) uses helper templates for dynamic naming and namespace assignment. The labels correctly assign the role “worker” to this DaemonSet.

---

8-13: Annotations in Metadata
The annotations are conditionally injected using .Values.worker.daemonsetAnnotations, offering flexibility without hardcoding values.

🧰 Tools

🪛 YAMLlint (1.35.1)

[warning] 9-9: wrong indentation: expected 2 but found 4

(indentation)

---

14-20: DaemonSet Spec & Selector for Worker
The DaemonSet’s specification, including the revision history limit and the label selector (using helper functions), is implemented correctly.

---

21-30: Pod Template Metadata for Worker
Pod-level metadata includes dynamic labels and a checksum annotation for configuration via the nfd-worker-conf ConfigMap. Conditional extra annotations add further customization as needed.

---

31-39: Pod Specifications: Policies & Secrets
The pod spec defines a DNS policy, optionally a priority class, and imagePullSecrets. The service account name is sourced via a helper, ensuring consistency.

---

40-42: Security & Network Settings
The security context and host network settings in the pod spec are clearly defined. Double-check that these settings meet both security and network performance expectations in your environment.

---

43-78: Worker Container Configuration
The container section for worker includes image referencing, a dedicated security context, and comprehensive liveness/readiness probe configurations using gRPC. The feature-gates are dynamically processed in the arguments, which is a versatile approach.

---

79-91: Environment Variables Injection
Environment variables such as NODE_NAME, POD_NAME, and POD_UID are sourced from the pod spec fields, which is essential for dynamic behavior within the container.

---

92-111: Container Command & Feature Gate Arguments
The container’s command and arguments leverage a loop to include feature gates dynamically. This design is efficient; ensure that the resultant command-line arguments match the container’s entrypoint expectations.

---

112-120: Port Definitions for Metrics & Health Checks
Port configurations for metrics and gRPC-health are clearly defined with default values. This is consistent with the topology updater’s approach.

---

121-180: Volume Mounts and Associated Host Paths
The volume mounts cover a broad range of host system paths (e.g. /host-boot, /host-os-release, /host-sys), and the conditional mount for /host-usr/src is appropriately guarded. Confirm that all host paths exist and are accessible on the target nodes.

---

181-194: Scheduling and Node Affinity Settings
The final section includes node selectors, affinity, tolerations, and an optional priorityClassName. These settings offer flexible scheduling; ensure they are aligned with your operational requirements.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/clusterrolebinding.yaml (6)

1-1: YAMLlint & Template Syntax Note
As with previous files, the templated syntax at the top of the file may trigger YAML lint warnings. This is expected in Helm charts.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

1-16: ClusterRoleBinding for Master Role
The first ClusterRoleBinding is conditionally created based on .Values.master.enable and .Values.master.rbac.create. It correctly binds the master ClusterRole to the appropriate ServiceAccount as defined by the helper template.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

18-19: YAML Document Separator Usage
The use of the document separator (--- on line 19) properly denotes the start of a new resource document within the file.

---

18-34: ClusterRoleBinding for Topology Updater
This block creates a binding for the topology updater by appending “-topology-updater” to the name and correctly referring to the service account. All labels and templated fields are consistent with the naming conventions established in the chart.

---

36-37: YAML Document Separator Usage
Another document separator (--- on line 37) is used correctly to separate multiple resources.

---

36-52: ClusterRoleBinding for Garbage Collection (GC)
The GC binding is conditionally created using the GC flags and binds the GC-specific ClusterRole to its ServiceAccount. The namespace is dynamically set, ensuring proper scope.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/clusterrole.yaml (5)

1-1: Helm Template Note for ClusterRole Definition
Like the other templates, the opening templated syntax may raise YAML lint warnings. This is typical for Helm-managed YAML files.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

1-8: Master ClusterRole Metadata
The first ClusterRole (lines 1–8) sets up metadata using helper templates for the name and labels. This promotes consistency across the platform.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

9-58: Master ClusterRole Rules Configuration
The rules in this section comprehensively cover access to namespaces, nodes (and nodes/status), and NFD-specific resources (nodefeatures, nodefeaturerules, and nodefeaturegroups). Coordination lease permissions are also granted. Overall, the rules are well segmented by API group and are appropriate for the master’s functions.

---

60-102: Topology Updater ClusterRole Rules
The ClusterRole for the topology updater allows access to nodes, namespaces, pods (and nodes/proxy), as well as permissions on noderesourcetopologies in the topology.node.k8s.io API group. The defined verbs (create, get, update) seem appropriate for updating resource topology.

---

104-140: Garbage Collection ClusterRole Rules
The GC ClusterRole grants permissions for listing, watching, and deleting nodes and node features, as well as managing node resource topologies. This minimal yet sufficient set of permissions helps enforce the principle of least privilege for garbage collection operations.

packages/system/gpu-operator/charts/gpu-operator/templates/_helpers.tpl (3)

1-32: Well-structured Helm template helpers following best practices.

The template functions for chart name, fullname, and chart label generation follow standard Helm best practices. The code properly handles name truncation to 63 characters and suffix trimming to comply with Kubernetes DNS naming requirements. The fullname logic correctly handles cases where release name contains chart name.

---

34-66: Good implementation of label management.

The labeling system properly follows Kubernetes recommended label standards with app.kubernetes.io prefixes. I like how you've separated common labels, operand-specific labels, and match labels into distinct templates. The inclusion of optional custom labels from Values is a nice flexibility feature.

---

68-80: Clean implementation of image reference helpers.

The fullimage template helpers provide a consistent way to construct image references throughout the chart. This approach will make image management more maintainable as it centralizes the logic for constructing full image paths.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/_helpers.tpl (3)

1-43: Well-structured NFD helper templates with good namespace flexibility.

The Node Feature Discovery templates follow Helm chart best practices with proper name and fullname handling. The additional namespace override feature (lines 27-36) is particularly useful for multi-namespace deployments in combined charts, providing flexibility for deployment scenarios.

---

45-63: Clear separation of label concerns.

The templates properly separate common labels from selector labels, which is a good practice for Kubernetes resources. The reuse of the selectorLabels template in the common labels template is efficient and promotes consistency.

---

65-107: Well-designed service account naming system.

The multiple service account naming templates provide good flexibility:

• They handle creation/non-creation scenarios
• They allow for explicit name overrides
• They follow a consistent pattern across different components (master, worker, topology updater, garbage collector)

This approach will make RBAC configuration cleaner and more maintainable.

Reviewing files that changed from the base of the PR and between 78af5e2 and 68eb9a2.

• packages/system/gpu-operator/charts/gpu-operator/Chart.lock is excluded by !**/*.lock

• packages/core/platform/bundles/paas-full.yaml (1 hunks)
• packages/system/gpu-operator/Chart.yaml (1 hunks)
• packages/system/gpu-operator/Makefile (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/.helmignore (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/Chart.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/.helmignore (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/Chart.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/README.md (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/crds/nfd-api-crds.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/_helpers.tpl (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/clusterrole.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/clusterrolebinding.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/master.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/nfd-gc.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/nfd-master-conf.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/nfd-topologyupdater-conf.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/nfd-worker-conf.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/post-delete-job.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/prometheus.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/role.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/rolebinding.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/serviceaccount.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/topologyupdater-crds.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/topologyupdater.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/worker.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/values.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/crds/nvidia.com_nvidiadrivers.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/_helpers.tpl (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/cleanup_crd.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/clusterpolicy.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/clusterrole.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/clusterrolebinding.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/dcgm_exporter_config.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/mig_config.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/nodefeaturerules.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/nvidiadriver.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/operator.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/plugin_config.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/readonlyfs_scc.openshift.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/role.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/rolebinding.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/serviceaccount.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/upgrade_crd.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/values.yaml (1 hunks)
• packages/system/gpu-operator/values-talos.yaml (1 hunks)
• packages/system/gpu-operator/values.yaml (1 hunks)
• packages/system/kubevirt/templates/kubevirt-cr.yaml (1 hunks)

• packages/system/kubevirt/templates/kubevirt-cr.yaml
• packages/system/gpu-operator/values.yaml
• packages/system/gpu-operator/Chart.yaml
• packages/system/gpu-operator/values-talos.yaml
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/.helmignore
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/Chart.yaml
• packages/core/platform/bundles/paas-full.yaml
• packages/system/gpu-operator/charts/gpu-operator/.helmignore
• packages/system/gpu-operator/charts/gpu-operator/Chart.yaml

packages/system/gpu-operator/charts/gpu-operator/templates/mig_config.yaml (3)

1-1: Ensure Correct Helm Templating Conditional Syntax

The conditional on line 1 uses Helm templating correctly to check that both the migManager.config.create flag is set and that the migManager.config.data is non-empty. This ensures the ConfigMap is created only when valid data is provided.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

2-9: Verify ConfigMap Definition and Dynamic Data Population

The ConfigMap definition (lines 2–9) adheres to the expected structure:

• The API version (v1) and kind (ConfigMap) are correctly specified.
• Dynamic metadata fields such as name ({{ .Values.migManager.config.name }}) and namespace ({{ .Release.Namespace }}) are set as intended.
• The labels are populated using the included helper template, and the data is converted from YAML with proper indentation using toYaml ... | nindent 2.
  This implementation properly leverages Helm templating for dynamic configuration.

---

10-10: Check Templating Block Closure

The templating block is correctly closed with {{- end }} on line 10, which safely concludes the conditional rendering.

packages/system/gpu-operator/charts/gpu-operator/templates/dcgm_exporter_config.yaml (3)

1-2: Ensure Conditional ConfigMap Creation is Thoroughly Guarded

The conditionals correctly verify that a configuration exists (.Values.dcgmExporter.config), the create flag is set, and the data field is non-empty before instantiating the ConfigMap. This prevents accidental resource creation when the configuration is missing or incomplete.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

3-7: Validate ConfigMap Metadata Setup

The apiVersion, kind, and metadata (including name and namespace) are assembled appropriately using Helm templating constructs. Using {{ .Values.dcgmExporter.config.name }} and {{ .Release.Namespace }} ensures that the ConfigMap aligns with dynamic deployment context.

---

8-12: Confirm Label Inclusion and Data Formatting

The labels are injected via the helper template ({{- include "gpu-operator.labels" . | nindent 4 }}) and the data block for dcgm-metrics.csv is properly indented using nindent 4. This approach should produce valid YAML output as long as the helper template returns correctly formatted labels.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/prometheus.yaml (1)

1-1: Helm Templating Directive Context
The {{- if .Values.prometheus.enable }} directive is a standard Helm template conditional. Be aware that standard YAML linters may flag this line as a syntax error because they do not process Helm templating.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/gpu-operator/charts/gpu-operator/templates/plugin_config.yaml (1)

1-1:

Details

✅ Verification successful

Resolve Templating Syntax and Trailing Spaces in ConfigMap Template

Static analysis indicates a syntax error at line 1—likely due to the leading whitespace control operator ({{-) in the conditional—and trailing spaces at the end of the file (line 11). This can be improved by removing the dash on the opening if statement and cleaning up any trailing spaces.

-{{- if and (.Values.devicePlugin.config.create) (not (empty .Values.devicePlugin.config.data)) }}
+{{ if and (.Values.devicePlugin.config.create) (not (empty .Values.devicePlugin.config.data)) }}

Also, please remove any trailing spaces (e.g., on line 11).

Also applies to: 11-11

---

Resolve Templating Syntax & Remove Trailing Spaces

In the file packages/system/gpu-operator/charts/gpu-operator/templates/plugin_config.yaml, please update the template as follows:

• Line 1: Replace the opening tag to remove the whitespace control operator. Change

  {{- if and (.Values.devicePlugin.config.create) (not (empty .Values.devicePlugin.config.data)) }}

  to

  {{ if and (.Values.devicePlugin.config.create) (not (empty .Values.devicePlugin.config.data)) }}

• Line 11: Remove any trailing spaces.

This adjustment resolves the static analysis warning regarding templating syntax and ensures that no extraneous whitespace remains in the file.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/gpu-operator/charts/gpu-operator/templates/role.yaml (1)

8-85: Role Rules Structure Check
The rules for various API groups and resources are comprehensive and well organized. Ensure that the trailing content after line 84 (or the extra "85" marker) does not inadvertently result in an empty or malformed YAML node.

packages/system/gpu-operator/Makefile (3)

1-4: Makefile Variables and Exports
The variable definition using awk (with proper escaping via $$) and the export of NAME and NAMESPACE follow expected Makefile conventions. Please double-check that the referenced file (charts/cilium/Chart.yaml) exists and that the output of the awk command meets expectations.

---

6-7: Including Shared Makefiles
The inclusion of common-envs.mk and package.mk appears to be appropriate for sharing environment settings and packaging rules. No issues identified.

---

9-13: Update Target Implementation
The update target cleanly removes the existing charts directory, adds the NVIDIA Helm repository, updates it, and pulls the GPU operator chart using Helm. This target is straightforward and meets the intended purpose.

packages/system/gpu-operator/charts/gpu-operator/templates/clusterrole.yaml (1)

143-155: Conditional Cleanup for CRDs
The conditional inclusion of the delete verb based on .Values.operator.cleanupCRD is a neat use of Helm templating. Verify that the conditional block indents correctly after templating so that the list of verbs remains valid YAML.

packages/system/gpu-operator/charts/gpu-operator/templates/cleanup_crd.yaml (1)

37-44: Command Block in Cleanup Container
The multiline command in the container definition is clearly structured and leverages Helm conditionals for optional extra deletion commands (for NFD). Ensure that the use of the block scalar with > preserves the intended command formatting when the template is rendered.

packages/system/gpu-operator/charts/gpu-operator/templates/operator.yaml (7)

17-24: Annotations and Labels under Pod Metadata
The pod metadata correctly uses templating for injecting labels and annotations. Ensure that the toYaml call for annotations (line 23) returns a properly indented YAML map compatible with Kubernetes metadata.

---

26-31: Image Pull Secrets Block
The conditional block for imagePullSecrets is well structured using range. No issues noted; just ensure that the secrets are defined properly in the values file when they are expected.

---

35-51: Container Configuration and Conditional Logging Args
The container specification for gpu-operator is comprehensive. The use of conditionals for devel mode (--zap-devel) versus production logging options (time encoding and level) is handled cleanly. Test that the generated command-line arguments form a valid list when the values are provided, as misconfigured logging flags can lead to unexpected behavior at runtime.

---

53-64: Environment Variables & Volume Mounts
The environment variables (including the dynamic OPERATOR_NAMESPACE from the pod field reference) and volume mounts for accessing /etc/os-release are correctly configured.

---

65-76: Liveness and Readiness Probes
The health probes are well defined, with reasonable delays and timeouts. These settings appear to align with common practices for Kubernetes Deployments.

---

77-84: Resource and Port Configurations
The conditional inclusion of resource requests/limits using toYaml is neatly integrated. The definition of the metrics port is also properly set.

---

85-99: Node Selectors, Affinity, and Tolerations
The final blocks correctly pull node selection strategies, affinity rules, and tolerations from values. Ensure that their rendered output maintains proper YAML indentation.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/master.yaml (2)

4-13: Metadata & Annotations Block
The metadata section (lines 4–13) correctly uses conditional inclusion for deployment annotations. Please double-check that the included labels and annotations (using include and toYaml) render with the expected indentation when the template is rendered.

🧰 Tools

🪛 YAMLlint (1.35.1)

[warning] 9-9: wrong indentation: expected 2 but found 4

(indentation)

---

45-64: Container Probe Configurations
The container configuration (lines 45–64) for startup, liveness, and readiness probes with gRPC settings is comprehensive. Verify that the default port values and delay/timeout parameters in .Values.master.*Probe.* are set consistently with operational expectations.

packages/system/gpu-operator/charts/gpu-operator/templates/nvidiadriver.yaml (1)

60-67: Conditional Configuration Blocks
The CRD includes several conditional blocks (for annotations, labels, nodeSelector, imagePullSecrets, manager, etc.). Verify that these sections are activated only when their corresponding values are provided in the values file. This will ensure a flexible CRD configuration for different deployment scenarios.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/role.yaml (1)

9-24: Role Rules Configuration
The Role’s rules (lines 9–24) grant access to nodefeatures in the nfd.k8s-sigs.io API group and allow read access for pods. The structure is correct; however, double-check that the leading dashes for list items are correctly indented relative to rules: when rendered. This will help avoid potential YAML parsing issues.

packages/system/gpu-operator/charts/gpu-operator/values.yaml (4)

1-7: Default GPU Operator Configuration: Platform and NFD

The initial sections set up the platform configuration and Node Feature Discovery (NFD) settings in a clear and well-commented manner. These defaults appear sensible; just confirm they align with your target deployment environment.

---

12-18: CDI and Sandbox Workloads Settings

The configuration for CDI (Container Device Interface) and sandbox workloads is neat and self-explanatory. Verify that the chosen default values (e.g. defaultWorkload: "container") match your operational expectations.

---

23-30: HostPaths Configuration

The hostPaths section documents critical paths (rootFS and driverInstallDir) clearly. Ensure that the runtime environment provides the necessary permissions and that these values remain consistent with your host's filesystem structure.

---

35-51: Daemonsets and Validator Configuration

The sections for daemonsets, including labels, annotations, tolerations, and update strategies, are well structured. Make sure the image repositories and pull policies (as defined later in the file) conform to your cluster’s security guidelines.

packages/system/gpu-operator/charts/gpu-operator/templates/readonlyfs_scc.openshift.yaml (2)

1-1: Template Conditional Rendering

The conditional check {{- if .Values.platform.openshift }} is appropriately used to include this SecurityContextConstraints (SCC) template only in OpenShift environments. Confirm that your values correctly toggle this behavior.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

14-19: SCC Security Settings

The security settings disable host IPC, network, PID, and related capabilities while allowing controlled privilege escalation. These settings are appropriate for a restrictive SCC. Verify that they meet your operational and security requirements.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/nfd-gc.yaml (6)

1-1: Conditional Deployment for GC

The Deployment is wrapped in a conditional ({{- if and .Values.gc.enable -}}) that correctly controls its inclusion. Ensure that the value provided for .Values.gc.enable is consistent with your intended deployment behavior.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

2-13: Deployment Metadata and Annotations

The metadata block leverages templated inclusions (for name, namespace, and labels) and conditionally includes deployment annotations using toYaml. This approach promotes consistency across resources—just verify that the included templates (e.g. "node-feature-discovery.labels") render the expected labels.

---

14-30: Deployment Spec and Selector

The Deployment spec uses templated values for replica count and revision history limit, and its selector labels (with the additional role: gc) are appropriately defined. Confirm that these values suit your scaling and update strategies.

---

31-39: Pod Security and Networking

The pod template specifies the service account, DNS policy (ClusterFirstWithHostNet), priority class, and image pull secrets dynamically. The security context imported from .Values.gc.podSecurityContext adds consistency to your security posture. Ensure these settings are intentional.

---

40-75: Container Configuration for GC

The container configuration details the image composition, pull policy, and environment variables—including dynamic injection of the node name. The conditional inclusion of GC interval arguments is a nice touch. Verify that resource requests, security restrictions (e.g. no privilege escalation and read-only root filesystem), and the metrics port configuration meet the expected operational parameters.

---

76-87: Node Scheduling Constraints

The templated sections for nodeSelector, affinity, and tolerations are implemented using toYaml and provide the needed flexibility for scheduling. Double-check that these constraints effectively target the intended nodes in your cluster.

packages/system/gpu-operator/charts/gpu-operator/templates/clusterpolicy.yaml (8)

1-13: ClusterPolicy Metadata and Conditional Annotations

The ClusterPolicy resource is defined with the appropriate API version and kind. The conditional injection of the "helm.sh/resource-policy": keep annotation (when operator.cleanupCRD is true) is a smart safeguard to prevent duplicate deletions. Verify that this cleanup logic is thoroughly tested.

🧰 Tools

🪛 YAMLlint (1.35.1)

[warning] 7-7: wrong indentation: expected 2 but found 4

(indentation)

---

[error] 6-6: syntax error: expected the node content, but found '-'

(syntax)

---

15-26: Spec HostPaths and Operator Configuration

The spec block’s hostPaths and operator sections dynamically incorporate values such as rootFS, driverInstallDir, runtimeClass, and defaultGPUMode. This flexible design helps tailor the deployment. Confirm that these templated defaults are in line with your infrastructure.

---

46-64: Daemonsets Settings

The configuration for daemonsets includes templated labels, annotations, tolerations, priority class, update strategy, and rolling update settings. Using toYaml here ensures proper formatting. Verify that these settings reflect your desired update behavior for GPU-related pods.

---

65-88: Validator Component Configuration

The validator section covers multiple sub-fields such as repository, image, version (with a fallback to .Chart.AppVersion), image pull policy, secrets, resources, environment variables, and even plugin configurations. This thoroughness is commendable; just ensure that every conditional block renders correctly in your helm templates.

---

131-139: MIG, PSA, and CDI Configuration

The inclusion of MIG strategy, PSA enablement, and CDI settings is succinct and clear. These flags are critical to driver installation and resource management—confirm that their defaults align with your operational intent.

---

140-234: Driver Configuration and Upgrade Policy

The driver section is extensive, covering enablement flags, CRD usage, kernel module types, precompiled package options, and a detailed upgrade policy. The structured approach here facilitates granular control during driver upgrades. Ensure that numeric values (e.g. in upgradePolicy) are quoted or cast appropriately to avoid type issues in YAML.

---

235-345: Enhanced Operator Components Configuration

The subsequent blocks for components like vgpuManager, kataManager, vfioManager, and others are modular and follow a consistent templating style. It’s important to verify the interdependencies among these components (e.g., driver managers within vGPU or VFIO sections) through integration tests.

---

346-681: Comprehensive ClusterPolicy Specification for GPU Operator

The remaining portion of the file covers a wide array of configurations—from device plugins and DCGM (Data Center GPU Manager) to GFD, migManager, nodeStatusExporter, and sandbox-specific settings. The extensive use of conditional templating and toYaml ensures flexibility. Given the file’s complexity, thorough testing and validation against the Kubernetes API schema are recommended to ensure all optional fields and nested configurations render as expected.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/crds/nfd-api-crds.yaml (3)

1-123: NodeFeature CRD Definition Looks Solid
The NodeFeature CRD provides a comprehensive schema with detailed descriptions for its fields. Ensure that any custom processing of the raw feature data is documented in your operator’s docs.

---

124-392: NodeFeatureGroup CRD Defines Grouping Rules Clearly
The NodeFeatureGroup CRD is well structured, offering clear specifications for grouping rules and status reporting. Consider adding usage examples in the documentation to assist operators in leveraging this resource effectively.

---

395-712: NodeFeatureRule CRD is Well-Structured and Comprehensive
The NodeFeatureRule CRD thoroughly defines configuration rules for customizing node objects, including annotations, labels, taints, and variable templating. Verify that the cluster-scoped nature of this CRD is intentional and documented since it differs from the others.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/clusterrole.yaml (3)

1-59: Master ClusterRole Configuration is Comprehensive
The master ClusterRole grants permissions for namespaces, nodes, and NFD-specific resources (including coordination leases for leader election). Confirm that these permissions adhere to the principle of least privilege and are fully in line with your operator’s security policies.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

60-102: Topology Updater ClusterRole is Appropriately Scoped
The ClusterRole for the topology updater covers access to nodes, namespaces, and specialized resources (like node proxies and pod access). Ensure that the corresponding Helm value conditions are well documented so that operators know when this role is created.

---

104-141: Garbage Collection ClusterRole Defined Correctly
The GC-related ClusterRole provides the necessary permissions to list, watch, and delete relevant node features and topologies. Review these permissions periodically to ensure they remain consistent with any evolving security policies.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/worker.yaml (1)

1-196: Worker DaemonSet Template Looks Detailed and Functional
Overall, the worker DaemonSet template is comprehensive—it configures security contexts, liveness/readiness probes, resource limits, environment variables, and volume mounts accurately. Verify that all referenced Helm values (e.g. image repository, tag defaults, probe settings) are correctly defined in your values files.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

[warning] 9-9: wrong indentation: expected 2 but found 4

(indentation)

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/clusterrolebinding.yaml (3)

1-16: Well-structured master ClusterRoleBinding with proper conditionals

The ClusterRoleBinding for the master component is properly conditional on both .Values.master.enable and .Values.master.rbac.create, ensuring it will only be created when both conditions are met. The binding uses appropriate helper templates for consistent naming and labeling.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

18-34: Topology updater ClusterRoleBinding follows best practices

The ClusterRoleBinding for the topology updater component follows the same pattern as the master component, with appropriate conditional logic. The suffix -topology-updater helps distinguish this binding while maintaining naming consistency with the corresponding ClusterRole.

---

36-52: Garbage collector ClusterRoleBinding is well-defined

This ClusterRoleBinding for the garbage collector component is correctly conditional and follows the established pattern. All three bindings in this file maintain a consistent structure, making the template easy to understand and maintain.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/topologyupdater-crds.yaml (4)

1-10: CRD creation properly conditional with appropriate annotations

The NodeResourceTopology CRD is correctly conditional based on topology updater enablement and CRD creation flag. The metadata includes important annotations such as API approval reference and controller-gen version, following Kubernetes best practices.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

11-139: Well-defined v1alpha1 schema with comprehensive property details

The v1alpha1 schema for NodeResourceTopology is thorough and well-documented. It includes detailed descriptions for all properties and proper validation constraints. Note that this version has the topologyPolicies field as a required field, while it's deprecated in v1alpha2.

---

139-272: v1alpha2 schema appropriately handles API evolution

The v1alpha2 schema correctly marks topologyPolicies as deprecated while maintaining backward compatibility. This version also removes it from the required fields list (line 268), showing proper API evolution. Setting storage: true for this version indicates it's the preferred storage version.

---

272-278: Status field initialization follows CRD standard

The status field initialization with empty values for acceptedNames and storedVersions follows the standard pattern for CRDs. This section will be managed by the Kubernetes API server once the CRD is applied.

packages/system/gpu-operator/charts/gpu-operator/templates/_helpers.tpl (3)

1-33: Core helper functions follow Helm best practices

The basic helper functions for name, fullname, and chart follow Helm best practices. They properly handle name overrides, truncation to 63 characters to comply with Kubernetes limits, and appropriate formatting for chart labels.

---

34-67: Label helper functions provide consistent labeling

The label helper functions ensure consistent labeling across resources. The inclusion of conditional labels from values (lines 46-48 and 54-56) allows for additional custom labels while maintaining the required standard labels. The matchLabels function appropriately includes only the subset of labels typically used in selectors.

---

68-80: Image helper functions enable flexible image configuration

The image helper functions for the GPU operator and driver manager construct full image references from component parts (repository, image name, version). This approach gives users flexibility to configure each part independently while maintaining a consistent pattern.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/_helpers.tpl (3)

1-44: Core NFD helper functions well-documented and implemented

The name, fullname, namespace, and chart helper functions are well-documented and follow Helm conventions. The namespace function (lines 30-36) adds flexibility by allowing namespace override, which is useful for multi-namespace deployments.

---

45-64: Label functions provide consistent resource identification

The labels and selectorLabels functions ensure consistent labeling across NFD resources. The separation of selectorLabels is a good practice, as it provides the minimal set of labels needed for selectors while the full labels function includes additional metadata like version and managed-by.

---

65-107: Service account name functions handle multiple components elegantly

The service account name helper functions for different components (master, worker, topology updater, and garbage collector) follow a consistent pattern. Each properly handles both cases where service accounts are created by the chart or externally provided. The default naming conventions with component-specific suffixes (e.g., -worker, -topology-updater) ensure clear distinction between components.

Reviewing files that changed from the base of the PR and between 68eb9a2 and 1e27ded.

• packages/system/gpu-operator/charts/gpu-operator/Chart.lock is excluded by !**/*.lock

• packages/core/platform/bundles/paas-full.yaml (1 hunks)
• packages/system/gpu-operator/Chart.yaml (1 hunks)
• packages/system/gpu-operator/Makefile (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/.helmignore (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/Chart.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/.helmignore (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/Chart.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/README.md (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/crds/nfd-api-crds.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/_helpers.tpl (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/clusterrole.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/clusterrolebinding.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/master.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/nfd-gc.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/nfd-master-conf.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/nfd-topologyupdater-conf.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/nfd-worker-conf.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/post-delete-job.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/prometheus.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/role.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/rolebinding.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/serviceaccount.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/topologyupdater-crds.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/topologyupdater.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/worker.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/values.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/crds/nvidia.com_nvidiadrivers.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/_helpers.tpl (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/cleanup_crd.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/clusterpolicy.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/clusterrole.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/clusterrolebinding.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/dcgm_exporter_config.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/mig_config.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/nodefeaturerules.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/nvidiadriver.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/operator.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/plugin_config.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/readonlyfs_scc.openshift.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/role.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/rolebinding.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/serviceaccount.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/templates/upgrade_crd.yaml (1 hunks)
• packages/system/gpu-operator/charts/gpu-operator/values.yaml (1 hunks)
• packages/system/gpu-operator/values-talos.yaml (1 hunks)
• packages/system/gpu-operator/values.yaml (1 hunks)
• packages/system/kubevirt/templates/kubevirt-cr.yaml (1 hunks)

• packages/system/gpu-operator/values.yaml
• packages/system/gpu-operator/Chart.yaml
• packages/system/kubevirt/templates/kubevirt-cr.yaml
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/.helmignore
• packages/system/gpu-operator/Makefile
• packages/system/gpu-operator/charts/gpu-operator/.helmignore
• packages/core/platform/bundles/paas-full.yaml
• packages/system/gpu-operator/values-talos.yaml
• packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/Chart.yaml
• packages/system/gpu-operator/charts/gpu-operator/Chart.yaml

packages/system/gpu-operator/charts/gpu-operator/templates/dcgm_exporter_config.yaml (6)

1-2: Ensure Robust Conditional Checks for ConfigMap Generation

The nested conditionals correctly guard the creation of the ConfigMap and ensure that both the create flag is true and the data value is non-empty. Verify that your values file always defines the expected keys, or consider adding default values if not set.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

3-4: ConfigMap Declaration is Clear

The apiVersion: v1 and kind: ConfigMap lines are correctly defined according to Kubernetes specifications.

---

5-7: Proper Use of Metadata with Dynamic Values

Using Helm templating to set the ConfigMap's name and namespace is correctly implemented. Ensure that .Values.dcgmExporter.config.name is provided in your values file and that it meets naming conventions for Kubernetes resources.

---

8-9: Dynamic Label Injection via Template Include

The inclusion of labels with {{- include "gpu-operator.labels" . | nindent 4 }} is a good practice for maintaining consistency and reusability. Make sure the gpu-operator.labels template is defined and returns valid YAML.

---

10-12: Proper Formatting of Multiline Data Block

Using the literal block scalar (|) along with nindent 4 on the DCGM metrics data helps ensure that the inline values are correctly indented. This approach preserves the formatting of the CSV content as expected.

---

1-1: Note on YAMLlint Static Analysis Error

The YAMLlint error regarding the unexpected '-' in line 1 is a false positive. Helm template directives (e.g., {{- if ... }}) sometimes trigger such warnings, but they are normal in this context and can be safely ignored.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/topologyupdater-crds.yaml (1)

2-9: CRD Metadata Definition

The metadata block is well-structured with clear annotations including the API approval and the controller-gen version. Just verify that setting creationTimestamp: null is intentional in a Helm-managed context, as this field is typically populated during deployment.

packages/system/gpu-operator/charts/gpu-operator/values.yaml (1)

1-606: Overall Configuration File – Well-Documented and Comprehensive

This new values file provides an extensive and well-commented configuration for the GPU operator. The various sections (platform, NFD, driver, manager, etc.) are clearly structured with informative inline comments.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/README.md (1)

1-11: README Clarity and Informative Content

The README provides a clear introduction to Node Feature Discovery (NFD), outlining its role in detecting hardware features and labeling nodes. It also includes an external link for deployment instructions, which is very helpful for users.

🧰 Tools

🪛 LanguageTool

[grammar] ~5-~5: Possible agreement error. The noun ‘vendor’ seems to be countable; consider using: “range of vendors”.
Context: ...uration and extension points for a wide range of vendor and application specific node labeling ...

(A_COLLECTIVE_OF_NN)

---

[uncategorized] ~6-~6: When ‘application-specific’ is used as a modifier, it is usually spelled with a hyphen.
Context: ...n points for a wide range of vendor and application specific node labeling needs. See [NFD document...

(SPECIFIC_HYPHEN)

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/nfd-topologyupdater-conf.yaml (1)

1-13: Helm Template for ConfigMap is Well-Structured
The conditional creation of the ConfigMap with the if block and the use of toYaml with nindent are correctly implemented. Note that the YAMLlint error on line 1 (expected node content but found ‘‑’) is likely a false positive triggered by Helm’s templating syntax. If necessary, configure your linting tool to ignore Helm templates.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/gpu-operator/charts/gpu-operator/templates/rolebinding.yaml (1)

8-11: Verify Subjects List Indentation
The subjects field should be a properly indented YAML sequence. Confirm that the dash on line 9 is correctly placed relative to the subjects: key. Typically, it should appear two spaces further in than the key.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/prometheus.yaml (1)

1-1: Ignore Helm Templating False Positive
The syntax error reported on line 1 (expected node content but found ‘‑’) is a known false positive caused by Helm template delimiters. This can be safely ignored or excluded from YAMLlint.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/gpu-operator/charts/gpu-operator/templates/clusterrole.yaml (1)

153-155: Conditional CRD Cleanup Rule Validation

The conditional inclusion of the delete verb based on .Values.operator.cleanupCRD is correctly implemented. Just ensure that the resulting verbs list is valid and that the cleanup logic is well tested so that CRDs are deleted only when intended.

packages/system/gpu-operator/charts/gpu-operator/templates/operator.yaml (1)

35-42: Deployment Container Configuration Review

The container configuration—including environment variables, volume mounts, and resource definitions—is clear and leverages Helm templating effectively. No issues were detected here; the configuration looks well structured.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/master.yaml (1)

22-31: Annotations and Checksum in Pod Template

The annotations block—including the checksum of the ConfigMap from
{{ include (print $.Template.BasePath "/nfd-master-conf.yaml") . | sha256sum }}—is well implemented. Please double-check that the checksum correctly updates when the configuration changes.

packages/system/gpu-operator/charts/gpu-operator/templates/nvidiadriver.yaml (10)

1-12: Solid CRD Definition & Conditionals
The CRD definition for NVIDIADriver is clear and leverages Helm conditionals effectively (using {{- if ... }}) to control whether the default CRD is deployed. This ensures that users can enable or disable the deployment based on values.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

13-24: Effective Use of Conditional Optional Metadata
The conditional inclusion of optional fields—such as annotations, labels, node selectors, and image pull secrets—using toYaml and nindent is well implemented. Ensure the chosen indentation (6 spaces in most cases) aligns with your overall chart style guidelines.

---

25-36: Configuration Blocks for Manager and Probes
The optional blocks for the driver manager and for the startup, liveness, and readiness probes are clear and modular. This design supports flexible configuration while keeping the template maintainable.

---

37-42: RDMA and Tolerations Blocks
The RDMA configuration and the inclusion of tolerations via a conditional block are handled appropriately. Verify that the indentation (using nindent 6) meets your YAML style, especially since similar sections in other files have raised indentation concerns.

---

43-50: Optional Repo and Certificate Configurations
The conditional sections for repoConfig and certConfig are clear and consistent with the overall design, allowing users to supply custom configurations when needed.

---

51-55: Licensing Configuration
The licensingConfig block correctly defines a configuration for NVIDIA vGPU licensing, including a default for nlsEnabled (set to true).

---

56-63: Virtual Topology & Kernel Module Configuration
Both the virtualTopologyConfig and kernelModuleConfig sections are concise and conditionally rendered. Confirm that the field names and expected values are consistent with your Helm values file.

---

64-72: Resources, Environment, and Arguments
Using conditional blocks to include resources, environment variables (env), and command-line arguments (args) via toYaml keeps the template flexible and maintainable.

---

73-95: GDS Integration Block
The GPUDirectStorage (GDS) configuration is thorough, incorporating repository, image, version (with quoting), image pull policy, and image pull secrets. This detailed configuration facilitates extensive customization.

---

96-118: GDRCopy Configuration Block
The gdrcopy configuration mirrors the GDS block in structure and clarity. Its use of conditionals and default values (e.g. defaulting to false) ensures that additional settings are only applied when required.

packages/system/gpu-operator/charts/gpu-operator/templates/upgrade_crd.yaml (6)

1-11: ServiceAccount for Upgrade CRD Hook
The ServiceAccount is properly defined with pre-upgrade hook annotations (helm.sh/hook, hook-delete-policy, and hook-weight). This configuration is key to triggering the CRD upgrade process as part of the Helm lifecycle.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

12-32: ClusterRole Definition for CRD Management
The ClusterRole grants the necessary permissions on customresourcedefinitions—including create, get, list, watch, patch, and update—which is sufficient for managing CRDs during upgrades.

---

33-49: ClusterRoleBinding for Proper Authorization
The ClusterRoleBinding correctly associates the ServiceAccount with the ClusterRole while dynamically setting the namespace using {{ .Release.Namespace }}.

---

50-61: Job Metadata and Hook Annotations
The Job is configured with appropriate pre-upgrade hook annotations and labels. The hook weights are set deliberately (with values “0” and “1”); ensure these values reflect your desired execution order for hooks.

---

81-94: Container Configuration for Upgrade Job
The container’s configuration—including the image (sourced via include "gpu-operator.fullimage"), pull policy, and the multiline shell command that applies various CRD files—is implemented clearly. The conditional inclusion for applying the NFD API CRDs is also appropriately controlled.

---

94-95: Restart Policy Verification
The restart policy is set to OnFailure, which is typical for Job resources, ensuring the Job will retry only in failure situations.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/role.yaml (3)

1-9: Conditional Role Creation for Node Feature Discovery
This Role resource is conditionally rendered based on .Values.worker.enable and .Values.worker.rbac.create, and the metadata (name, namespace, and labels) is templated appropriately.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

10-18: Nodefeatures Permissions Rule
The first rule grants the necessary permissions (create, get, update, delete) for the nodefeatures resource in the nfd.k8s-sigs.io API group. This is well defined and follows RBAC best practices.

---

19-24: Pods Access Rule
The second rule, which provides minimal (get) access for pods in the core API group, minimizes over-privileging while still permitting necessary read operations.

packages/system/gpu-operator/charts/gpu-operator/crds/nvidia.com_nvidiadrivers.yaml (4)

1-28: CRD Header and Basic Specification
The CRD header is well defined with the proper apiVersion, kind, and metadata annotations (including the controller-gen version). The group, names (with short names), and scope are correctly specified, adhering to Kubernetes CRD conventions.

---

29-716: Extensive OpenAPI Schema for NVIDIADriverSpec
The openAPIV3Schema for NVIDIADriverSpec is highly comprehensive. It covers a wide array of configuration options including:

• Basic fields such as annotations, args, and certConfig.
• Core configurations like driverType (with a default value and immutability validation), env, gdrcopy, and gds.
• Image settings, kernel module configurations, labeling, and licensing configurations.
• Detailed probe configurations (liveness, readiness, startup) with appropriate thresholds and formats.
• Advanced runtime settings including resource limits/requests, node affinity, tolerations, and RDMA settings.

The schema uses proper type declarations, enumeration, regex patterns, and even includes x-kubernetes-validations to enforce immutability for certain fields. This rigorous schema will help validate user input and prevent misconfigurations.

---

717-804: Status Schema Definition
The status section of the CRD is clearly structured with a detailed conditions array. Each condition includes essential fields such as lastTransitionTime, message, reason, status, and type—all with proper validations (e.g. length limits and regex patterns). This level of detail should greatly aid in accurately reporting and diagnosing the state of installed NVIDIA drivers.

---

806-810: CRD Serving and Subresource Settings
The CRD is marked as served and the subresource for status is enabled. These settings ensure the CRD is available for API operations and allows status updates independently.

packages/system/gpu-operator/charts/gpu-operator/templates/readonlyfs_scc.openshift.yaml (9)

1-13: Conditional SCC for OpenShift
This template conditionally renders the SecurityContextConstraints (SCC) for OpenShift when .Values.platform.openshift is enabled. The metadata—comprising labels (using the chart’s helper) and a descriptive annotation—is well defined, providing useful context about the SCC’s restrictions.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

[error] 10-10: trailing spaces

(trailing-spaces)

---

14-20: Host Feature and Privilege Restrictions
The SCC explicitly disables host directory volume plugins, IPC, network, PID, and host ports while allowing privilege escalation (without permitting privileged containers). This strict configuration aligns well with a hardened security posture.

---

21-22: Capabilities Configuration
Both allowedCapabilities and defaultAddCapabilities are set to empty arrays, ensuring that no extra Linux capabilities are inadvertently granted.

---

23-24: Filesystem Group Enforcement
The fsGroup is set to MustRunAs, enforcing that pods run with a specific group—a solid practice for ensuring predictable filesystem permissions.

---

25-27: Groups and Priority Configuration
The inclusion of the system:authenticated group and a priority of 0 is appropriate to ensure that the SCC applies to all authenticated users at the intended precedence.

---

28-33: Read-Only Root and Capabilities Drop
The SCC mandates a read-only root filesystem and specifies a list of capabilities (KILL, MKNOD, SETUID, SETGID) to drop. This enforces a strict security environment for pods managed under this SCC.

---

34-37: User and SELinux Constraints
The settings for runAsUser (MustRunAsRange) and seLinuxContext (MustRunAs) ensure that pods run under controlled user and SELinux contexts.

---

38-39: Supplemental Groups Setting
Allowing supplemental groups to be set to RunAsAny is acceptable here, offering flexibility while maintaining other security constraints.

---

42-48: Allowed Volume Types
The list of allowed volume types is explicitly provided and limited to common and safe options such as configMap, downwardAPI, emptyDir, persistentVolumeClaim, projected, and secret. This restricts pod access to only approved storage options.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/nfd-gc.yaml (5)

1-13: Deployment Metadata and Labels:
The Deployment metadata uses dynamic naming and labeling (via include and toYaml), which helps to maintain consistency. Please verify that your values (e.g. those in .Values.gc) are defined correctly in your values file.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

14-23: Deployment Spec Configuration:
The spec sets the replica count and revision history limit based on values and correctly matches labels in the selector. Ensure that .Values.gc.replicaCount and .Values.gc.revisionHistoryLimit provide appropriate defaults.

---

44-50: Container Image and Environment Setup:
The container “gc” is configured with dynamic image repository/tag values and an environment variable (NODE_NAME) sourced from the node. Double-check that any extra environment variables added via .Values.gc.extraEnvs are well formatted.

---

55-64: Command Arguments Handling:
The conditional inclusion of the -gc-interval argument is clear and correctly implemented. Please verify that when .Values.gc.interval is set, the rendered argument meets your intended format.

---

65-79: Security Context and Scheduling Configurations:
The container’s security context (which restricts privilege escalation, sets a read-only root, etc.) and the pod scheduling settings (nodeSelector, affinity, tolerations) are well parameterized. Confirm that the corresponding values under .Values.gc are valid and meet your security and scheduling requirements.

packages/system/gpu-operator/charts/gpu-operator/templates/clusterpolicy.yaml (5)

1-7: ClusterPolicy Metadata and Labeling:
The metadata section effectively uses Helm templating to generate a dynamic name and labels (including the "app.kubernetes.io/component": "gpu-operator" label). Please confirm that this label structure aligns with your overall labeling strategy.

🧰 Tools

🪛 YAMLlint (1.35.1)

[warning] 7-7: wrong indentation: expected 2 but found 4

(indentation)

---

[error] 6-6: syntax error: expected the node content, but found '-'

(syntax)

---

8-13: Conditional Annotations for CR Cleanup:
Annotations for CR cleanup are added conditionally if .Values.operator.cleanupCRD is set. This avoids potential duplicate cleanup actions. Verify that this behavior matches your operator’s lifecycle expectations.

---

14-17: HostPaths Parameters:
The hostPaths for rootFS and driverInstallDir are parameterized. Ensure that the provided values in .Values.hostPaths are valid paths on your target nodes.

---

46-64: Daemonset Block Configuration:
The daemonset section (including labels, annotations, tolerations, priority, update strategy, etc.) is structured correctly using Helm functions. Please double-check options like the priorityClassName and rollingUpdate settings against your operational requirements.

---

65-517: Overall ClusterPolicy Resource Review:
This template is extensive and covers several operator components (validator, driver, MIG, PSA, CDI, etc.). Due to its complexity, thorough integration testing is recommended to ensure that all Helm value substitutions produce valid and usable configurations in your cluster.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/crds/nfd-api-crds.yaml (4)

1-1: Document Separator Check:
The file appropriately starts with a YAML document separator (---), which is expected when combining multiple documents. Confirm that your tooling supports multi-document YAML files.

---

1-123: NodeFeature CRD Review:
The NodeFeature CRD is defined with a detailed OpenAPIV3 schema outlining properties for features (attributes, flags, and instances) and labels. Verify that using additionalProperties and required fields meets your API contract for node feature discovery.

---

124-194: NodeFeatureGroup CRD Review:
This CRD provides a schema for grouping nodes based on discovered features. The featureGroupRules section is well described. Please test that the matchers behave as intended.

---

395-712: NodeFeatureRule CRD Review:
The NodeFeatureRule CRD supports the creation of node customization rules using complex matchers (matchAny, matchFeatures) along with annotations, labels, taints, and variable templates. Given its complexity, a careful review of schema validation rules is recommended to ensure they match your operational requirements.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/post-delete-job.yaml (4)

1-11: ServiceAccount for Post-Delete Hook:
The ServiceAccount is defined with a dynamic name and namespace and includes hook annotations (e.g. "helm.sh/hook": post-delete). This implementation looks good; just ensure the account receives only the necessary privileges.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 4-4: syntax error: expected , but found ''

(syntax)

---

12-32: ClusterRole for Node Pruning:
The ClusterRole specifies permissions (get, patch, update, list) for nodes and nodes/status, which are essential for the post-delete cleanup job. Verify that these permissions adhere to the principle of least privilege.

---

33-50: ClusterRoleBinding Association:
The ClusterRoleBinding cleanly links the ClusterRole to the ServiceAccount. This setup is appropriate for RBAC in cleanup operations.

---

51-95: Job Configuration for Post-Delete Cleanup:
The Job resource is configured to run the nfd-master binary with the -prune flag and conditionally adds an instance argument if provided. The hook annotations are in place for proper Helm hook handling. Please verify that resource requests (if defined elsewhere) and restart policies match your cluster’s needs.

🧰 Tools

🪛 YAMLlint (1.35.1)

[warning] 54-54: too many spaces after colon

(colons)

---

[warning] 66-66: wrong indentation: expected 6 but found 8

(indentation)

---

[warning] 70-70: wrong indentation: expected 6 but found 8

(indentation)

---

[warning] 76-76: wrong indentation: expected 10 but found 12

(indentation)

---

[warning] 78-78: wrong indentation: expected 10 but found 12

(indentation)

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/topologyupdater.yaml (7)

2-10: DaemonSet Metadata and Annotations:
Metadata (name, namespace, labels) is generated dynamically. The annotations include a checksum for the configuration file, which is a good practice to trigger pod restarts on config changes.

---

14-20: DaemonSet Selector and Template Labels:
The selector and pod template labels are managed using Helm helpers (e.g. include "node-feature-discovery.selectorLabels"). This ensures consistency between resource selectors and pod labels.

---

43-68: Container Probes and Health Checks:
Liveness and readiness probes are configured to use gRPC on a configurable port, with conditional inclusion of delay and timeout values. This robust setup is good; please ensure that the health check thresholds match your application’s behavior.

---

80-120: Command and Environment Configuration:
The container’s environment variables (NODE_NAME and NODE_ADDRESS) are correctly obtained via field references, and the command arguments are built using conditionals for update interval, watched namespace, and other options. Confirm that default values (such as a 3-second sleep interval) are appropriate for your deployment.

---

121-143: Ports and Volume Mounts Setup:
The container exposes metrics and health ports and mounts necessary host paths (e.g., for kubelet config and pod resources socket). Validate that paths like /host-var/kubelet-config and the fallback for the pod resources socket are correct for your target cluster.

---

144-188: Pod Scheduling Details:
Pod scheduling is enhanced with configurable node selectors, affinity rules, and tolerations. This allows flexible placement of topology updater pods. Just ensure that the values provided yield the intended scheduling behavior.

---

1-189: Overall Topology Updater Review:
This DaemonSet template is comprehensive, covering security, health checks, command arguments, volume mounts, and scheduling. Running helm template to review the final rendered YAML is recommended to validate correctness under your environment.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/clusterrole.yaml (3)

1-58: RBAC permissions for NFD master look appropriate

The ClusterRole for the node-feature-discovery master component contains the necessary permissions to manage node features, including namespaces, nodes, and NFD-specific resources. The conditional creation based on .Values.master.enable and .Values.master.rbac.create follows best practices for optional components.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

60-102: RBAC permissions for topology updater correctly scoped

The topology updater ClusterRole has appropriate permissions to access nodes, pods, and manage node resource topologies. The permissions align with the topology updater's responsibilities for managing hardware topology information.

---

104-140: RBAC permissions for garbage collector well-defined

The garbage collector ClusterRole contains the necessary permissions for cleaning up stale node features and node resource topologies when nodes are removed from the cluster. The permissions are correctly limited to list and delete operations on the relevant resources.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/worker.yaml (4)

1-42: Worker DaemonSet configuration looks appropriate

The DaemonSet configuration for the NFD worker component includes proper metadata, selectors, and pod specifications. The use of template helpers for naming and labels ensures consistency, and the checksum annotation on line 26 will trigger rolling updates when the configuration changes.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

[warning] 9-9: wrong indentation: expected 2 but found 4

(indentation)

---

43-111: Container configuration uses best practices

The worker container configuration includes:

• Proper security context
• Well-defined liveness and readiness probes using gRPC
• Downward API for node and pod information
• Configurable resource requests and limits
• Feature gate configuration

These settings follow Kubernetes best practices for containerized applications.

---

112-146: Volume mounts correctly configured as read-only

All host path mounts are properly configured as read-only, which is a security best practice when accessing host resources. The conditional mount for /usr/src (lines 136-140) provides flexibility when that directory is not needed.

---

147-194: Volume and scheduling settings look good

The volume definitions and scheduling settings (nodeSelector, affinity, tolerations) are well structured and provide flexibility for different deployment scenarios. The ConfigMap mounting for worker configuration is correctly implemented with specific item mapping.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/clusterrolebinding.yaml (3)

1-16: ClusterRoleBinding for master component is correctly configured

The ClusterRoleBinding properly connects the master ClusterRole to its ServiceAccount. The naming conventions are consistent and follow the pattern established in the ClusterRole definition.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

---

18-34: ClusterRoleBinding for topology updater looks good

The topology updater ClusterRoleBinding correctly links the topology updater ClusterRole to its ServiceAccount. The conditional creation based on feature enablement follows the same pattern as the ClusterRole.

---

36-52: ClusterRoleBinding for garbage collector is properly defined

The garbage collector ClusterRoleBinding appropriately connects the garbage collector ClusterRole to its ServiceAccount. The naming and namespace references are consistent with the other components.

packages/system/gpu-operator/charts/gpu-operator/templates/_helpers.tpl (3)

1-33: Helm naming helper templates follow best practices

The helper templates for chart names and application names correctly handle:

• Name truncation to 63 characters (Kubernetes limit)
• Suffix trimming
• Optional name overrides
• Proper chart version formatting

These patterns follow Helm best practices for resource naming.

---

34-66: Label templates provide consistent labeling across resources

The label templates create consistent sets of labels for different resources:

• Common labels for all resources
• Operand-specific labels
• Match labels for selectors

Including conditional custom labels from values provides flexibility while maintaining consistency.

---

68-80: Image name templates correctly handle repository and versioning

The templates for full image names properly combine repository, image name, and version information, with appropriate fallbacks to chart version when specific versions aren't provided.

packages/system/gpu-operator/charts/gpu-operator/charts/node-feature-discovery/templates/_helpers.tpl (3)

1-26: Well-structured Helm helper functions for name generation.

The chart name, fullname, and override-related helpers follow proper Helm chart practices with the appropriate truncation to 63 characters for Kubernetes naming constraints.

---

38-63: Correctly implemented chart label and selector label helpers.

The chart label and selector label helpers follow best practices for Kubernetes resource labeling, ensuring proper selection of resources and adherence to label standards.

---

65-107: Service account naming follows consistent patterns across components.

The service account naming helpers for master, worker, topology updater, and garbage collector components follow a consistent pattern:

1. Check if service account creation is enabled
2. Use specified name or generate appropriate default with component suffix
3. Fall back to "default" if not creating a service account

This approach handles service account configuration appropriately.