Repository navigation
kubernetes-nodes: refuse a leading-zero or unquoted-zero resources.cpu the way vm-instance does, after a migration of stored pools #4554
Description
The kubernetes-nodes and vm-instance charts write resources.cpu into the same KubeVirt field, domain.cpu.cores, but they accept different values. vm-instance refuses a leading zero and an unquoted zero since #4405. kubernetes-nodes still renders both, as main did before, and #4386 keeps it that way.
| Value | vm-instance | kubernetes-nodes |
|---|---|---|
"010" |
refused | renders cores: 010, which YAML reads as octal 8 |
0 (unquoted) |
refused | treated as unset, the pool is sized by its instancetype |
kubernetes-nodes can't just refuse them, because stored pools may already carry these values. Migration 56 copies resources verbatim from the parent Kubernetes CR's nodeGroups into each KubernetesNodes CR. Its pre-adoption guard skips container-typed fields, and resources is one of them. A render-time refusal without a migration would leave such a pool's release failing on every upgrade until someone edits the value by hand.
The leading zero is the case that matters. Whoever wrote "010" most likely meant ten cores, and the pool runs with eight and no error.
Proposed order:
- A numbered migration over every
KubernetesNodesCR and every parentnodeGroupsentry. It drops an unquotedcpu: 0, which renders the same template, so nothing rolls. It rewrites a leading-zero value to the decimal YAML already reads, so"010"becomes8. The size stays the same, but the template name changes, so that pool rolls once. Each rewrite should be logged, since the original value was probably a mistake. - After that, kubernetes-nodes refuses both values the same way vm-instance does.
The #4405 description says vm-instance follows "the same rule #4386 uses for kubernetes-nodes". That matched an earlier revision of #4386, not the current one.
Activity
lexfrei commentedon Sep 28, 2026
A leading zero also makes the chart disagree with itself. With
cpu: "010"the VM getscores: 010, which is 8 cores, but the kubelet reservation math and the autoscaler capacity annotation read the same value as 10:So the autoscaler believes each node in that pool has more CPU than the VM actually has. This is the same on
main, and the fix above covers it, because after the migration no leading-zero value reaches the template.fix(kubernetes-nodes): refuse a resources.cpu that cannot be a core c…
themoriarti commentedon Oct 19, 2026
Addressed in #4974, which fixes the inconsistency this issue describes without the migration and the render-time refusal: on kubevirt the kubelet reservations and the autoscaler capacity annotation now derive from the YAML-decoded value the VM gets, so
"010"is eight cores on every side, with the emittedcores:bytes and the machine template name unchanged for every spelling. The reasons for not migrating are in the PR; if a migration is still wanted, please reopen after it merges.fix(kubernetes-nodes): size reservations from the cores the VM actual…
fix(kubernetes-nodes): plan autoscaler capacity on the cores the VM a…
fix(kubernetes-nodes): plan autoscaler capacity on the cores the VM a…
fix(kubernetes-nodes): refuse a partial resources spec on every pool (#…
fix(kubernetes-nodes): plan autoscaler capacity on the cores the VM a…
fix(kubernetes-nodes): plan autoscaler capacity on the cores the VM a…