neonvm: add architecture field to vm.spec

[mikhail-sakhnov]

Add spec.cpuArchitecture to use for scheduling pods instead of relying on spec.affinity.
Use spec.cpuArchitecture value while building the vm pod spec affinity.

Extracted from #1123

[github-actions]

No changes to the coverage.

HTML Report

Click to open

[sharnoff]

Just a couple thoughts

[sharnoff]

Sorry, a couple higher level things I realized w.r.t. rollout:

1. What happens to old VMs? Will k8s automatically default them to the new behavior? How will we make sure that they continue to get x86 if they restart?
2. What happens on rollback?

Given these: Maybe worthwhile to (a) remove the CRD default to x86, and (b) interpret nil as x86, until all clients have been updated? And then we can update all VM objects to set TargetArchitecture to x86 and change the controller to have nil handling in the way that we want.

---

Again, sorry for not realizing this sooner -- backwards/forwards compatibility can be really tricky to get right with this kind of thing.

[mikhail-sakhnov]

@sharnoff

What happens to old VMs? Will k8s automatically default them to the new behavior? How will we make sure that they continue to get x86 if they restart?

So in general, the old VMs have no materialized value for the field in the kube-api storage. When deploying a version with spec.targetArchitecture annotated with "kubebuilder:default:amd64", the lack of the set value will be interpreted as "amd64".

Indeed, if we rollback to the version without spec.targetArchitecture, the behaviour would be to ignore spec.targetArchutecture even if it is materialized in the kube-api storage. In practice, that would lead to always create a pod with nodeArchitecture affinity equal controller architecture.

If it feels safer, I changed the default value for spec.targetArchitecture to be nil and add code to explicitly set it to amd64 in vm_controller.go, by this we will have materialized values for all VMs after at least reconciliation.

However, in case of rollback, it doesn't change anything, since if we rollback, we rollback to the version which has no spec.targetArchitecture and function affinityForVirtualMachine will behave based on the controller architecture.

Did I answer your question, or should I elaborate deeper on something?

[sharnoff]

Looks good, modulo two comments