kubernetes-nodes emits resources.cpu straight into a uint32 cores field and decides precedence from the raw string #4150

packages/apps/kubernetes-nodes/templates/nodegroup.yaml reads resources.cpu twice, and both readings take the value as written rather than as it will land in the object.

Line 136 renders cores: {{ .group.resources.cpu }} with no coercion. domain.cpu.cores is a uint32 in KubeVirt's API, and the chart's schema types resources.cpu with the quantity grammar, so a nodegroup written with resources.cpu: 500m emits cores: 500m and the API server refuses the VirtualMachine outright.

Line 69 compounds it. $sizedByResources is and .group.resources .group.resources.cpu .group.resources.memory, which tests the raw string for truthiness, so 500m counts as sizing. The instancetype matcher is dropped on that basis, and what remains is a VM with neither a matcher nor a usable core count. Had the check read what the template actually emits, 500m would not have counted and the matcher would have stayed.

Both are the same underlying reading: the value the operator typed is not the value the object receives, and a quantity string is exactly where those two diverge.

The fix has a shape already used elsewhere in the tree for this field family: coerce through the integer conversion before emitting, and decide precedence from what the conversion produced rather than from the source string. packages/apps/vm-instance is being changed to do that for the same pair of concerns, so the reasoning and the test shapes can be copied rather than invented.

Worth handling in the same pass: resources.memory and any other quantity-typed field this template emits into an integer position, since the defect is a property of the type rather than of cpu.