-
Notifications
You must be signed in to change notification settings - Fork 425
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
Add DisableExtensionOperations field #4792
Add DisableExtensionOperations field #4792
Conversation
Hi @RadekManak. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
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.
I'm wondering if we should make this about disabling the bootstrapping extension rather than disabling all extensions, since we can already disable extensions by just adding an empty list?
Going even further, is this actually a three option case, no bootstrapping extension, the default bootstrapping extension, or a custom bootstrapping extension (if there's a difference between a bootstrapping extension and regular extension that is, though I'm not convinced it is?)
api/v1beta1/azuremachine_types.go
Outdated
// Specifies whether extension operations should be disabled on the virtual machine. This may only be set to True when no | ||
// extensions are configured on the virtual machine. | ||
// +optional | ||
DisableExtensionOperations *bool `json:"disableExtensionOperations,omitempty"` | ||
|
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.
When there are VMExtensions
provided, does the default extension still get added? I wonder if it would be better to disable the default extension rather than disable all so you don't have the awkward interaction between this field and the VMExtensions
field
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.
Yes the default extension is always added even if no extensions are specified. I'm wondering if there is a specific use-case for just disabling extension operations temporarily while VMExtensions
is specified. If that's not something you need, adding the option to disable will probably be enough.
/assign @willie-yao |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4792 +/- ##
==========================================
+ Coverage 62.01% 62.06% +0.04%
==========================================
Files 201 201
Lines 16858 16922 +64
==========================================
+ Hits 10455 10503 +48
- Misses 5620 5634 +14
- Partials 783 785 +2 ☔ View full report in Codecov by Sentry. |
/ok-to-test |
allErrs := field.ErrorList{} | ||
|
||
if ptr.Deref(disableExtensionOperations, false) && len(vmExtensions) > 0 { | ||
allErrs = append(allErrs, field.Forbidden(field.NewPath("AzureMachineTemplate", "spec", "template", "spec", "VMExtensions"), "VMExtensions must be empty when DisableExtensionOperations is true")) |
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.
Judging by the logic here, it seems like this check is unnecessary. If the goal is to disable the default extension, a flag to explicitly do that would be better. That way, it's still possible to specify additional extensions without using the default one, and avoid confusion about the two conflicting 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.
The intent of disableExtensionOperations is to disable all VMExtension for the machine. This check is run in webhook to reject the machine template. Setting disableExtensionOperations true and configuring VMExtension would at best result with no VMExtension deplyoed (unexpteced behavior) and at worst machine failing to provision.
/test pull-cluster-api-provider-azure-e2e-optional |
05357d1
to
266cb60
Compare
My original idea with I have changed the PR to add |
266cb60
to
8d4749a
Compare
Ah that makes sense. It might be good to log a warning in the webhook if user's do specify VMExtensions while also disabling the bootstapping extension since if they are disabling it, it probably means the VM does not support extensions. |
I was investigating this issue independently; so was happy to discover this PR. As is, the PR solves the problem we have with RHCOS being unable to run extensions. LGTM. At risk of bikeshedding, if there is a chance that future extensions could be added by default, it might be better to relabel this |
8d4749a
to
1860d2f
Compare
I don't think there will be more default VMExtensions in the future. I've kept it as is, unless maintainers disagree, then I can change it. |
+1. This LGTM. |
api/v1beta1/azuremachine_types.go
Outdated
// Its role is to detect and report Kubernetes bootstrap failure or success. | ||
// Use this setting only if VMExtensions are not supported by your image. | ||
// +optional | ||
DisableBootstrappingVMExtension *bool `json:"disableBootstrappingVMExtension,omitempty"` |
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.
@RadekManak sorry for the confusion, I was following this effort from the edge but didn't make the effort to comment. I actually prefered the previous "disable all VM extensions" option. I think that is a more clarifying option to fulfill your problem, and would help other users in a similar scenario where VM extensions are not supported.
Disabling this particular extension doesn't make a lot of sense as you lose an explicit part of the CAPI bootstrapping contract guarantee; but it does make sense if your CAPZ VM scenario doesn't allow extensions that we want to ship a VM configuration with no Extensions in the configuration.
IMO
We'll prioritize merging this change w/ the previous implementation, thank you so much for this and for your patience!
1860d2f
to
50d4e21
Compare
Changed it back to DisableExtensionOperations and added a note explaining that it should only be used when VMExtensions are not supported by the image and that it disables the bootstrapping extension. |
/retest |
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.
Looks good pending one comment!
// Use this setting only if VMExtensions are not supported by your image, as it disables CAPZ bootstrapping extension used for detecting Kubernetes bootstrap failure. | ||
// This may only be set to True when no extensions are configured on the virtual machine. | ||
// +optional | ||
DisableExtensionOperations *bool `json:"disableExtensionOperations,omitempty"` |
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.
I'm thinking this field should be immutable since it doesn't make too much sense to disable extensions after the VM is already provisioned. Can you add an immutability check in ValidateUpdate
? https://github.com/willie-yao/cluster-api-provider-azure/blob/5243ae7d5dae9483280e73da2904a3568fbf8839/api/v1beta1/azuremachine_webhook.go#L77
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.
Thanks for pointing this out. I thought that the entire spec was immutable and did not check. Fixed.
32674b2
to
ca5e9c1
Compare
This option when set to true ensures no that no VMExtension are configured on the machine by preventing users to add values to VMExtensions field in machine template, Disabling the bootstrapping VMExtension and setting AllowExtensionOperations false in the instance osProfile.
ca5e9c1
to
087217a
Compare
@@ -213,6 +213,13 @@ func (mw *azureMachineWebhook) ValidateUpdate(ctx context.Context, oldObj, newOb | |||
allErrs = append(allErrs, err) | |||
} | |||
|
|||
if err := webhookutils.ValidateImmutable( | |||
field.NewPath("spec", "disableExtensionOperations"), |
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.
field.NewPath("spec", "disableExtensionOperations"), | |
field.NewPath("spec", "DisableExtensionOperations"), |
This should also be fixed for capacityReservationGroupID
on line 210. Sorry for not catching this in the previous PR!
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.
Changed to use the capitalized variant. capacityReservationGroupID
should be fixed in its own PR.
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.
Why with a capital? This breaks Kube API conventions. The path is supposed to take the json serialisation representation of the field name, so a camelCase
is correct.
Adding DisableExtensionOperations
with a capital means the error that comes back prints an incorrect JSON path
The capacityReservationGroupID
is correct and should not be changed
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.
Hmm you're definitely correct. I'm seeing some inconsistencies in the use of field.NewPath()
in CAPZ and that should definitely be fixed. Apologies for the confusion there!
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.
This PR is changed back to camelCase.
087217a
to
20e053a
Compare
20e053a
to
087217a
Compare
/retest |
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
cc @jackfrancis for approval
@willie-yao: GitHub didn't allow me to request PR reviews from the following users: for, approval. Note that only kubernetes-sigs members and repo collaborators can review this PR, and authors cannot review their own PRs. 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-sigs/prow repository. |
LGTM label has been added. Git tree hash: a04d0a356a205765a7281ea2b4b83cb2bf421bc8
|
/approve Thank you @RadekManak @JoelSpeed! |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jackfrancis 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 |
What type of PR is this?
/kind feature
What this PR does / why we need it:
This PR adds a new field to machine spec DisableExtensionOperations that when set to true ensures that no VMExtensions are configured on the machine by preventing users to add values to VMExtensions field in machine template and setting AllowExtensionOperations false in the instance osProfile.
Setting DisableExtensionOperations also disables the bootstrap failure detection VMExtension.
The intent of this change is to provide a way to create VMs that use images without the capability of running VMExtensions. Currently, these machines get stuck waiting for the bootstrapping VMExtension to get installed.
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 #
Special notes for your reviewer:
TODOs:
Release note:
/cc @damdo @JoelSpeed