-
Notifications
You must be signed in to change notification settings - Fork 351
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
HOSTEDCP-1826: review Azure API #4963
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: enxebre 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 |
✅ Deploy Preview for hypershift-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
@enxebre: This pull request references HOSTEDCP-1826 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.18.0" version, but no target version was set. 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 openshift-eng/jira-lifecycle-plugin repository. |
e1c8643
to
8d9735e
Compare
4acaf33
to
fe47f8f
Compare
/lgtm |
/test e2e-aks |
/test e2e-aks |
api/hypershift/v1beta1/azure.go
Outdated
// AvailabilityZone is the failure domain identifier where the VM should be attached to. This must not be specified | ||
// for clusters in a location that does not support AvailabilityZone. | ||
// availabilityZone is the failure domain identifier where the VM should be attached to. | ||
// This must not be specified for clusters in a location that does not support AvailabilityZone because... TODO: why? |
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.
because... TODO: why?
It will fail to provision? We should create availability sets instead if not specified?
// MachineIdentityID is a user-assigned identity assigned to the VMs used to authenticate with Azure services. This | ||
// field is expected to exist under the same resource group as HostedCluster.Spec.Platform.Azure.ResourceGroupName. This | ||
// machineIdentityID is a user-assigned identity assigned to the VMs used to authenticate with Azure services. The | ||
// identify is expected to exist under the same resource group as HostedCluster.Spec.Platform.Azure.ResourceGroupName. This | ||
// user assigned identity is expected to have the Contributor role assigned to it and scoped to the resource group | ||
// under HostedCluster.Spec.Platform.Azure.ResourceGroupName. | ||
// | ||
// If this field is not supplied, the Service Principal credentials will be written to a file on the disk of each VM | ||
// in order to be accessible by the cloud provider; the aforementioned credentials provided are the same ones as | ||
// HostedCluster.Spec.Platform.Azure.Credentials. However, this is less secure than using a managed identity. | ||
// | ||
// TODO: What is the valid character set for this field? What about minimum and maximum lengths? | ||
// | ||
// +optional | ||
MachineIdentityID string `json:"machineIdentityID,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 thought we were removing machine identity cc @bryan-cox
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.
From the API, yeah we still need to. I can put in a follow up PR if Alberto doesn't want to do that here. This PR is essentially blocking the cert work.
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, let's follow up in different PR for that.
/retest |
api/hypershift/v1beta1/azure.go
Outdated
// +optional | ||
AvailabilityZone string `json:"availabilityZone,omitempty"` | ||
AvailabilityZone int32 `json:"availabilityZone,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.
Can we change this to a string?
In CAPZ this is a string https://capz.sigs.k8s.io/reference/v1beta1-api#infrastructure.cluster.x-k8s.io/v1beta1.AzureMachineTemplateResource, as well as in Azure (https://learn.microsoft.com/en-us/rest/api/compute/resource-skus/list?view=rest-compute-2024-07-01&tabs=HTTP#resourceskulocationinfo) instead of an integer. I understand that it currently maps to integers but if validation is desired that can be performed anyway with a string, but we would be consistent with what's in Azure and we also give space in case in the future changes, which is why I suspect Azure / CAPZ have them as strings and not integers too.
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 had the same thought, I don't think we can have guarantees that azure will never introduce a different string that can't be mapped to a int. cc @JoelSpeed since you first introduce the change, any objections?
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 potential to not be an integer in the future is a fair one
What about using the kube IntOrString type? That would mean we don't have to force users to quote their integers, but, does it make validation harder? Perhaps
What validation can we impose now if we make this a string type, to ensure the zones provided are only "1"
, "2"
and "3"
as we currently expect them to be?
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.
What validation can we impose now if we make this a string type, to ensure the zones provided are only "1", "2" and "3" as we currently expect them to be?
Yes. In the future that validation then can then be relaxed if needed
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.
What about using the kube IntOrString type? That would mean we don't have to force users to quote their integers, but, does it make validation harder? Perhaps
For me a string would be just fine. I don't see the need of coupling it to kube IntOrString or add more complexity. In Azure/CAPZ they don't do that.
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.
ok thanks! I choose to go with a string for simplicity, future flexibility while still keeping validation UX
/lgtm |
/hold cancel |
/retest |
/hold |
/hold cancel |
/test e2e-aws-4-17 |
@enxebre: all tests passed! Full PR test history. Your PR dashboard. 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. I understand the commands that are listed here. |
[ART PR BUILD NOTIFIER] Distgit: hypershift |
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, use
fixes #<issue_number>(, fixes #<issue_number>, ...)
format, where issue_number might be a GitHub issue, or a Jira story:Fixes #
Checklist