docs: Def NVIDIA driver and migration by mikemckiernan · Pull Request #459 · NVIDIA/cloud-native-docs

mikemckiernan · 2026-08-10T17:52:23Z

Documents https://github.com/NVIDIA/cloud-native-team/issues/245

Review HTML:

Updates for mode on the driver CRD. The same page has the migration.
Update to the driver upgrade page to move the upgrade procedure here. I made a guess that with the enhancements, we'd want more visibility into the capabilities. LMK if you prefer it back on the driver CRD page.

github-actions · 2026-08-10T17:55:56Z

Documentation preview

https://nvidia.github.io/cloud-native-docs/review/pr-459

rahulait · 2026-08-10T19:46:37Z

+First, upgrade to v26.7.0 while retaining cluster policy driver management.
+Then, upgrade the same release again to enable NVIDIA driver custom resource management.
+This sequence starts the controller that supports controlled migration before changing driver ownership.
+Do not upgrade from an earlier release and enable NVIDIA driver custom resource management in the same


Suggested change

Do not upgrade from an earlier release and enable NVIDIA driver custom resource management in the same

Do not upgrade from an earlier release (using clusterpolicy for driver management) and enable NVIDIA driver custom resource management in the same

My instinct is to nuke the whole "Do not..." para. I think the instruction that precedes it and the procedure that follows are abundantly clear.

Sure, sounds good to me.

rahulait · 2026-08-10T19:48:45Z

+During the migration, the Operator assigns each GPU node to an NVIDIA driver custom resource and uses the
+driver upgrade controller to replace the previous cluster policy managed driver pod on each node.
+
+When you migrate from a GPU Operator release earlier than v26.7.0, perform two Helm upgrades.


Suggested change

When you migrate from a GPU Operator release earlier than v26.7.0, perform two Helm upgrades.

When you migrate from a GPU Operator release earlier than v26.7.0, perform two Helm upgrades. Clusters on or after v26.7.0 don't need the two step upgrade and can switch from clusterpolicy to nvidiadriver in a single upgrade.

Two things:

First, I'd prefer to avoid introducing the two-upgrade process for < 26.7.0 and then immediately provide the counterpoint circumstance before a human reader even reads the rationale for the two-upgrade process.

Second, the conditional in the procedure seems sufficiently clear: #. If your current GPU Operator release is earlier than v26.7.0, upgrade....

My concern is that if we try to handle "< 26.7.0 and >= 26.7.0" sentence-by-sentence, that we're taxing the attention span of our human readers.

Documents NVIDIA/cloud-native-team#245 Signed-off-by: Mike McKiernan <mmckiernan@nvidia.com>

Signed-off-by: Mike McKiernan <mmckiernan@nvidia.com>

rahulait · 2026-08-21T03:39:32Z

+          --set operator.upgradeCRD=true \
+          --set driver.nvidiaDriverCRD.enabled=false \
+          --set driver.nvidiaDriverCRD.deployDefaultCR=false \


Do we need to set these (as they are the same as default value in chart)? We can avoid specifying them to avoid confusion where one might think these are always required.

mikemckiernan force-pushed the mmck-docs-migrate-driver branch 3 times, most recently from 88a2ad1 to d16a2f7 Compare August 10, 2026 18:36

mikemckiernan self-assigned this Aug 10, 2026

mikemckiernan requested a review from rahulait August 10, 2026 18:58

mikemckiernan force-pushed the mmck-docs-migrate-driver branch from d16a2f7 to e62f157 Compare August 10, 2026 19:11