fix(kubernetes): make node group resources optional when instanceType is set - #3121

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a validation issue where the resources block was strictly required for Kubernetes node groups, preventing configurations that relied solely on instanceType for sizing. By marking resources as optional in the schema and API types, the change enables more flexible node group definitions. The fix ensures that explicit resource overrides remain functional while resolving the installation-time validation errors previously encountered.

Highlights

• Schema Validation: Updated the Kubernetes node group schema to make the resources block optional, allowing node groups to be sized exclusively by instanceType.
• Documentation: Updated README and values documentation to reflect that resources is now optional and that instanceType provides the default sizing when omitted.
• Testing: Added helm-unittest coverage to verify that node groups without resources pass validation and that explicit resources are still correctly honored when provided.

No actionable comments were generated in the recent review. 🎉

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Thanks for tackling this — making resources optional (the #3046 path) is clearly right. One flag on the fail-fast on "both set", plus a small alternative that also closes the dashboard side.

The gap fail-fast leaves open

instanceType is required and defaulted to u1.medium in values.schema.json, so a node group effectively always carries an instanceType. The moment a user fills in resources.cpu/resources.memory while that default is present, the render now hard-fails:

nodeGroup md0: set either instanceType or explicit resources (cpu/memory), not both …

To use explicit resources they must also set instanceType: "". That's non-obvious from the CR, and impossible from the dashboard: the instanceType field is a required dropdown (x-cozystack-options: {source: instancetype}) with no empty option, so a console user who sets CPU/memory can't clear instanceType and is stuck. So fail-fast turns a silent KubeVirt rejection into a clear error, but the resources-sizing path stays unreachable for the common case.

Proposal: resolve by precedence instead of failing

When a node group is sized by explicit resources (both cpu and memory), omit the instancetype from the rendered VM. KubeVirt then accepts the explicit domain.cpu/domain.memory (no instancetype to conflict with), instanceType can stay required+defaulted (no schema change), and the dashboard works unchanged — sending u1.medium + explicit resources just sizes by resources (no UI change).

This keeps the #3046 case working (instanceType-only → instancetype rendered, no domain.cpu/memory), keeps the kubelet-reservation partial-override tests green (partial resources are untouched), and additionally fixes the separate "Save ignored when explicit resources are set" dashboard report. Verified locally with helm unittest (all green).

Suggested change on top of this PR (keeps your schema change), in templates/cluster.yaml:

       {{- range .group.roles }}
       node-role.kubernetes.io/{{ . }}: ""
       {{- end }}
     spec:
-      {{- with .group.instanceType }}
+      {{- /* Explicit resources take precedence over instanceType. When a node
+             group is sized by resources (both cpu and memory set), the
+             instancetype is omitted from the VM: KubeVirt rejects a
+             VirtualMachine that references an instancetype and also overrides
+             both domain.cpu and domain.memory. */}}
+      {{- $sizedByResources := and .group.resources .group.resources.cpu .group.resources.memory }}
+      {{- if and .group.instanceType (not $sizedByResources) }}
       instancetype:
         kind: VirtualMachineClusterInstancetype
-        name: {{ . }}
+        name: {{ .group.instanceType }}
       {{- end }}

and replace the fail-fast guard with the per-group resource flags (the lookup is also skipped when resources are the sizing source, so a stale instancetype can't fail an otherwise valid group):

 {{- range $groupName, $group := .Values.nodeGroups }}
-{{- if and $group.instanceType $group.resources (or $group.resources.cpu $group.resources.memory) }}
-{{-   fail (printf "nodeGroup %s: set either instanceType or explicit resources (cpu/memory), not both — KubeVirt rejects a VM that overrides instanceType CPU/memory" $groupName) }}
-{{- end }}
+{{- $hasCpu := and $group.resources $group.resources.cpu }}
+{{- $hasMem := and $group.resources $group.resources.memory }}
 {{- $instanceType := dict }}
-{{- if $group.instanceType }}
+{{- if and $group.instanceType (not (and $hasCpu $hasMem)) }}
 {{-   $instanceType = (lookup "instancetype.kubevirt.io/v1beta1" "VirtualMachineClusterInstancetype" "" $group.instanceType) }}
 {{-   if not $instanceType }}
 {{-     fail (printf "nodeGroup %s: specified instanceType %q not found in cluster" $groupName $group.instanceType) }}
 {{-   end }}
 {{- end }}

The existing "fails when both set" unittest then flips to assert the VM is sized by resources with no instancetype (documentIndex 4: domain.cpu.cores=2, domain.memory.guest=4Gi, spec.instancetype absent).

I've got this implemented and helm unittest-green on a branch based on this PR's head if it's useful — happy to push it to your branch or fold it in here, whichever you prefer. (Heads up: the PR currently shows conflicts with main, so a rebase is needed regardless.)

Aleksei Sviridkin (@lexfrei) please correct wording of PR and release note and resolve conflicts

Backport failed for release-1.5, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin release-1.5
git worktree add -d .worktree/backport-3121-to-release-1.5 origin/release-1.5
cd .worktree/backport-3121-to-release-1.5
git switch --create backport-3121-to-release-1.5
git cherry-pick -x a349c753ad16a68e309177562b18f54cf86ce4f9

Backport failed for release-1.4, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin release-1.4
git worktree add -d .worktree/backport-3121-to-release-1.4 origin/release-1.4
cd .worktree/backport-3121-to-release-1.4
git switch --create backport-3121-to-release-1.4
git cherry-pick -x a349c753ad16a68e309177562b18f54cf86ce4f9