-
Notifications
You must be signed in to change notification settings - Fork 431
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
✨ enable BYO IP for control plane #652
Conversation
Skipping CI for Draft Pull Request. |
/test all |
/test all |
/test pull-cluster-api-provider-azure-e2e |
I think BYOR (bring your own resource) is common across almost all resources. What do folks think about allowing the ProviderID to be set by a user, and the controller would use the ProviderID being set on an unowned resources as the indication the resource should be a BYO? |
Can we get this pull request to completion? Need this functionality to move forward with our deployment. |
I think at the very least, this PR needs to add a concept of ownership so that CAPZ doesn't delete IPs brought by the user and does not fail to cleanup IPs it creates. We've discussed this as a general issue a bit, @devigned @CecileRobertMichon any thoughts on how you think it should look for this particular use case? @MirzaSikander feel free to take over and drive this PR if you need the functionality sooner as mentioned offline |
For us, deleting the IP address is actually preferred so its not an issue for us. We can always extend it later to optionally delete it. |
Could we tag managed pubIPs with In the longer term, I don't know that we want to use only resource name as the way we look up resources. Using resource ID would be more precise. Moreover, I'm worried that if we pull this in quickly, then decide on a generic way of accepting "bring your own" resources, then this could be a painful migration in the next api version. |
Just wanted to provide our context and use case for this feature. We are team in Azure that is responsible for managing bare-metal infra in locations external to Azure DC aka the edge. We are in the process of layering k8s on top of our bare-metal infra to allow containerized apps to be deployed and managed. Our current topology involves the control plane deployed in Azure managing worker nodes on a private network in the edge. The master has a public IP address through which the workers are able to join the cluster. We wanted to transition over to CAPZ to avoid manually managing these clusters (Only the control plane as of now). For things to work properly we need to specify the advertise-address on the API-server
Currently there is no way CAPI/KCP to dynamically do this. (If there is maybe we can try that approach) With this pull request, we can sort of get around that by pre-provisioning a static IP address and populating the cluster configuration. |
Ok... This has been hanging around for a little while. It need to come to a conclusion. I don't love having name required on IPAddress. What if we leave the IPAddress type as it was, and just check with ARM if the IPAddress exists if name is set? If it does exist, we use it, else create it and tag it with CAPZ managed tag. On delete, we would not delete the IPAddress if it is tagged with the CAPZ managed tag. Thoughts? |
Yep, I think that approach makes sense. This is my next task up, I got a little distracted by a flurry of work on disks again -_- Thankfully all finished with that |
if err != nil { | ||
return errors.Wrapf(err, "failed to delete public ip %s in resource group %s", publicIPSpec.Name, s.Scope.ResourceGroup()) | ||
} | ||
|
||
klog.V(2).Infof("deleted public ip %s", publicIPSpec.Name) | ||
return err | ||
} | ||
|
||
func (s *Service) isManaged(ctx context.Context, name string) (bool, error) { |
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.
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.
will review and follow the approach! thanks!
@alexeldeib this will need a pretty big rebase since #716 merged... sorry about that |
@CecileRobertMichon if it's fine with you i'll leave the validation as is. I updated the PR title and description since this implementation is no longer breaking. lmk if you have additional comments? |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/test pull-cluster-api-provider-azure-test |
/test pull-cluster-api-provider-azure-test |
9c1982a
to
3213055
Compare
err := s.Client.Delete(ctx, s.Scope.ResourceGroup(), ip.Name) | ||
if err != nil && azure.ResourceNotFound(err) { | ||
// already deleted | ||
return 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.
good catch 😬
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.
one last comment about the FQDN, otherwise lgtm
Signed-off-by: Alexander Eldeib <alexeldeib@gmail.com>
@MirzaSikander I know this ended up taking quite a bit longer than anticipated, would appreciate if you have a chance to take a quick look at this for your scenario. @CecileRobertMichon force pushed but added DNS name and pass it through directly |
/test pull-cluster-api-provider-azure-e2e |
/assign @MirzaSikander |
@alexeldeib: PR needs rebase. 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. |
@alexeldeib: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
/close closing in favor of #974 |
@CecileRobertMichon: Closed this PR. 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. |
What this PR does / why we need it:
Enables users to bring their own IP for the control plane. This allows using a CAPI control plane with self-managed nodes by setting advertise address on KCP at create-time.
Defaults to previous behavior if unset. Updating this field is invalid.
Special notes for your reviewer:
Demo for Azure edge scenarios
Release note: