🐛 Do not drop spec.affinity on up convert#1467
Open
aruneshpa wants to merge 1 commit intovmware-tanzu:mainfrom
Open
🐛 Do not drop spec.affinity on up convert#1467aruneshpa wants to merge 1 commit intovmware-tanzu:mainfrom
aruneshpa wants to merge 1 commit intovmware-tanzu:mainfrom
Conversation
If a VM is created on v1alpha2 API version, conversion webhooks
store the object marshaled at v1alpha5 (storage version) on the object.
Then, when the object is modified again on v1alpha2 version so that
now the payload contains the spec.affinity, our conversion code simply
restores the field from the stored annotation -- completely dropping
the field during conversion. Instead, what should happen is that the
field should correctly be preserved and our validation webhooks should
deny that since affinity is an immutable fields.
Testing Done:
- Currently:
- 1. Create a VM on v1alpha2
```
root@422833dbe3475f4c8d61f99e674e934d [ ~ ]# cat v1a2vm.yaml
apiVersion: vmoperator.vmware.com/v1alpha2
kind: VirtualMachine
metadata:
name: parunesh-vm
namespace: parunesh-ns
spec:
className: best-effort-small
storageClass: wcpglobal-storage-profile
imageName: jammy-server-cloudimg-amd64
powerState: PoweredOn
bootstrap:
cloudInit: {}
```
- 2. Patch VM to specify Affinity (should succeed -- confirms bug)
```
root@422833dbe3475f4c8d61f99e674e934d [ ~ ]# kubectl apply --server-side=false -f - <<'EOF'
apiVersion: vmoperator.vmware.com/v1alpha2
kind: VirtualMachine
metadata:
name: parunesh-vm
namespace: parunesh-ns
spec:
className: best-effort-small
storageClass: wcpglobal-storage-profile
imageName: jammy-server-cloudimg-amd64
powerState: PoweredOn
bootstrap:
cloudInit: {}
affinity:
vmAffinity:
requiredDuringSchedulingPreferredDuringExecution:
- topologyKey: topology.kubernetes.io/zone
labelSelector:
matchLabels:
my-label: my-value
EOF
virtualmachine.vmoperator.vmware.com/parunesh-vm configured
```
- But with patched VM Operator, the same patch request fails:
```
root@422833dbe3475f4c8d61f99e674e934d [ ~ ]# kubectl apply --server-side=false -f - <<'EOF'
apiVersion: vmoperator.vmware.com/v1alpha2
kind: VirtualMachine
metadata:
name: parunesh-vm
namespace: parunesh-ns
spec:
className: best-effort-small
storageClass: wcpglobal-storage-profile
imageName: jammy-server-cloudimg-amd64
powerState: PoweredOn
bootstrap:
cloudInit: {}
affinity:
vmAffinity:
requiredDuringSchedulingPreferredDuringExecution:
- topologyKey: topology.kubernetes.io/zone
labelSelector:
matchLabels:
my-label: my-value
EOF
Error from server (spec.affinity: Forbidden: updating Affinity is not allowed): error when applying patch:
{"spec":{"affinity":{"vmAffinity":{"requiredDuringSchedulingPreferredDuringExecution":[{"labelSelector":{"matchLabels":{"my-label":"my-value"}},"topologyKey":"topology.kubernetes.io/zone"}]}}}}
to:
Resource: "vmoperator.vmware.com/v1alpha2, Resource=virtualmachines", GroupVersionKind: "vmoperator.vmware.com/v1alpha2, Kind=VirtualMachine"
Name: "parunesh-vm", Namespace: "parunesh-ns"
for: "STDIN": error when patching "STDIN": admission webhook
"default.validating.virtualmachine.v1alpha5.vmoperator.vmware.com"
denied the request: spec.affinity: Forbidden: updating Affinity is not
allowed
```
Minimum allowed line rate is |
sbueringer
reviewed
Feb 18, 2026
| } | ||
| } | ||
|
|
||
| func restore_v1alpha5_VirtualMachineAffinity(dst, src *vmopv1.VirtualMachine) { |
There was a problem hiding this comment.
I think with this change you lose affinity if you have clients that have v1alpha2 structs without the field like old capv versions
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do, and why is it needed?
If a VM is created on v1alpha2 API version, conversion webhooks store the object marshaled at v1alpha5 (storage version) on the object.
Then, when the object is modified again on v1alpha2 version so that now the payload contains the spec.affinity, our conversion code simply restores the field from the stored annotation -- completely dropping the field during conversion. Instead, what should happen is that the field should correctly be preserved and our validation webhooks should deny that since affinity is an immutable fields.
Testing Done:
Please add a release note if necessary: