-
Notifications
You must be signed in to change notification settings - Fork 421
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
Support APIServerAccessProfile in AzureManagedControlPlane #1640
Support APIServerAccessProfile in AzureManagedControlPlane #1640
Conversation
Hi @richardchen331. 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. |
/ok-to-test |
d995729
to
6b1b825
Compare
/test pull-cluster-api-provider-azure-e2e-exp |
/assign @alexeldeib @LochanRn @nprokopic |
lgtm |
/lgtm |
@richardchen331 Great Job !! WDYT about adding spec for private clusters ? |
06effc8
to
3ea6026
Compare
AuthorizedIPRanges []string `json:"authorizedIPRanges,omitempty"` | ||
// EnablePrivateCluster - Whether to create the cluster as a private cluster or not. | ||
// +optional | ||
EnablePrivateCluster bool `json:"enablePrivateCluster,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.
If this field is optional, I believe a bool pointer *bool
would be better. Same for EnablePrivateClusterPublicFQDN
. WDYT?
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.
@nprokopic Thanks for your feedback! I'm pretty new to golang and cluster api, and my (limited) understanding of using a pointer is that we could differentiate between a zero value and a not specified value, but then we have to deal with nil
. For EnablePrivateCluster
, I think explicitly passing in a zero value (false
) is equivalent to not passing it (both tells Azure to not enable private cluster). Therefore I'm not aware of the benefit of using a pointer.
Could you help explain a bit more why a bool pointer is better? I think I must have missed something and I'd love to learn :) Thank you!
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.
It is part of the k8s API conventions:
Therefore, we ask that pointers always be used with optional fields that do not have a built-in nil value.
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.
Got it, thanks for the reference! I'll change the fields to use pointers.
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.
It is part of the k8s API conventions
I vaguely remembered something like that, and that we had a similar discussion for some other CAPZ type some time ago, just couldn't find it.
Thanks Cecile for referencing this.
/test pull-cluster-api-provider-azure-e2e-windows |
|
||
// setDefaultAPIServerAccessProfile sets the default APIServerAccessProfile for an AzureManagedControlPlane. | ||
func (r *AzureManagedControlPlane) setDefaultAPIServerAccessProfile() { | ||
if r.Spec.APIServerAccessProfile == nil { |
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.
nit: Is this required? Wouldn't just leaving nil
also work?
@CecileRobertMichon are there some other examples of setting default values like this?
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.
You are right, I don't think this is required. (I was thinking setting it so there will be less working in validation webhook, but i don't think this is a good idea, since it's not good for unit test)
c2955ef
to
590993a
Compare
/retest |
@richardchen331 can you please also update the managedclusters documentation about APIServerAccessProfile. @alexeldeib over all this PR looks fine to me now. Over to you for a final review. |
Sure. I'll rebase and update the documentation after the other open PR (#1680) is merged since they modify similar set of files :) |
590993a
to
0e0453e
Compare
@alexeldeib I just rebased this PR and also added documentation. Could you help take a final look? Thanks! |
/retest |
3 similar comments
/retest |
/retest |
/retest |
// PrivateDNSZone - Private dns zone mode for private cluster. | ||
PrivateDNSZone *string | ||
// EnablePrivateClusterPublicFQDN - Whether to create additional public FQDN for private cluster or not. | ||
EnablePrivateClusterPublicFQDN *bool |
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 believe this will default to true on AKS side if private cluster is enabled. should we let that happen, or default it inside CAPZ?
it would only mean that a user who explicitly sets it would trigger a no-op reconcile, and a user who wants to change it will be able to.
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 the feedback! I would slightly prefer letting AKS to handle the default. My rationales are:
- This is true for other fields as well (e.g. managedOutboundIPs, sku tier)
- We need to add some logic when choosing the default values (e.g. set
EnablePrivateClusterPublicFQDN
to true whenEnablePrivateCluster
is true) - Given 1,2, this will add some extra complexity to the CAPZ code
The downside is that there will be some unnecessary no-op reconciles, but i feel that's probably fine?
I'm open to change it if you feel strongly about it :)
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.
Fine w me, I asked because I know this defaulting to true has surprised some folks in the past
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.
But that’s really an aks issue
/test pull-cluster-api-provider-azure-e2e-exp probably related to the failures we've been discussing. I chatted a bit with @LochanRn about watch issues unrelated to the AKS backend issue, we still have some debugging to do |
/approve (adding both since this was already approved) one minor comment but not a blocker |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alexeldeib 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 |
/retest |
0e0453e
to
2707d8d
Compare
/retest |
/lgtm |
What type of PR is this?
/kind feature
What this PR does / why we need it:
Adds APIServerAccessProfile support in AzureManagedControlPlane.
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 #1605
Special notes for your reviewer:
Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.
TODOs:
Release note: