-
Notifications
You must be signed in to change notification settings - Fork 295
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🐛 Skip updating VMOp immutable fields #2566
🐛 Skip updating VMOp immutable fields #2566
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #2566 +/- ##
==========================================
- Coverage 64.67% 64.32% -0.36%
==========================================
Files 118 118
Lines 8539 8585 +46
==========================================
- Hits 5523 5522 -1
- Misses 2595 2630 +35
- Partials 421 433 +12 ☔ View full report in Codecov by Sentry. |
b6bd18c
to
178bf0c
Compare
/override pull-cluster-api-provider-vsphere-apidiff-main |
@srm09: Overrode contexts on behalf of srm09: pull-cluster-api-provider-vsphere-apidiff-main In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
178bf0c
to
b7a724c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First of all thanks for the PR!
This PR also contains some optimizations we might not want to cherry-pick.
Should we reduce this PR to the bare minimum required to solve the related issue and do the other changes on a separate PR?
That would come down to the changes in:
https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/pull/2566/files#diff-c2e693327f8831614b68401c025d9322280d92938f4a064bcd949656feb52770R179-R337
if I did not miss a point here.
This way it would also be more easily cherry-pickable.
pkg/services/vimmachine.go
Outdated
@@ -47,8 +47,31 @@ type VimMachineService struct { | |||
Client client.Client | |||
} | |||
|
|||
// GetMachinesInCluster returns a list of VSphereMachine objects belonging to the cluster. | |||
func (v *VimMachineService) GetMachinesInCluster( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't know if we should make this part of the VimMachineService. We don't even use v.Client
:think:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, since the client is a part of the VimMachineService
and VMopMachineService
, no use passing them in the function call. Missed that since most of it was copying over the function as is from the util package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a couple of nits from my side
76f70ab
to
4daa7e7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some more nits + please move the predicate relevant changes to a separate PR :-)
Signed-off-by: Sagar Muchhal <[email protected]>
4daa7e7
to
99f247e
Compare
Reverted all the irrelavant changes so that this one just handles skipping immutable fields |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
LGTM label has been added. Git tree hash: ce01bd84254186927aea547b9ac17a39d3909431
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: chrischdi The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/cherry-pick release-1.8 |
@chrischdi: once the present PR merges, I will cherry-pick it on top of release-1.8 in a new PR and assign it to you. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/cherry-pick release-1.7 |
@chrischdi: once the present PR merges, I will cherry-pick it on top of release-1.7 in a new PR and assign it to you. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@chrischdi: #2566 failed to apply on top of branch "release-1.8":
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@chrischdi: #2566 failed to apply on top of branch "release-1.7":
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
// NOTE: Set field-by-field in order to preserve changes made directly | ||
// to the VirtualMachine spec by other sources (e.g. the cloud provider) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the issue we wrote that the following fields are immutable:
- ImageName
- ClassName
- StorageClass
- ResourcePolicyName
Here we stop mutating / reconciling:
- ImageName
- ClassName
- StorageClass
- MinHardwareVersion
(MinHardwareVersion instead of ResourcePolicyName)
Q: Is this intended?
Additionally, @srm09 @chrischdi @fabriziopandini What do we think about making those 4 fields immutable on the VSphereMachine? (and also updating the godoc comments accordingly)
I think it's confusing if folks can update the fields and then they are just silently not reconciled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According vm-operator code it is als MinHardwareVersion:
https://github.com/vmware-tanzu/vm-operator/blob/main/webhooks/virtualmachine/v1alpha1/validation/virtualmachine_validator.go#L143-L149
but great catch, we should also have the same behaviour for ResourcePolicyName
!
Also +1 for making these immutable on CAPV side. We will have to introduce webhooks for vm-operator mode capv first!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
created #2595 to track this validating webhook part.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
What this PR does / why we need it:
VMOp mutation webhook updates the VMOp Spec.ImageName to a user-friendly name prefixed
vmi-
orcvmi-
. This causes the reconciliation of the VSphereMachine to fail since the controllers copy the all spec fields to the VMOpVirtualMachine
on every reconcile. Since imageName is an immutable field we see the below error:This patch ensures the immutable fields on the VMop VM Spec do not get set if these fields on the existing VM object are not empty.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #2430