Specify the subnet id for the External Network using the external cloud provider

[raildo]

/kind feature

Nowadays, CAPO will always choose the first subnet given the OPENSTACK_EXTERNAL_NETWORK_ID based on the current code [0]. Would be nice to have a new configuration option, something like OPENSTACK_EXTERNAL_SUBNET_ID where we could specify on which subnet of the external network, we want the cluster to get a Floating IP.

The use case that I have is when there is no floating IP available on this first subnet to be used, but we do have others subnets on the public network and I would like to choose another subnet with another range of FIPs for the cluster to be deployed, right now we can't do it.

[0] https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/pkg/cloud/services/networking/router.go#L168

We have something similar to that already one on OCCM as you can see here:

https://github.com/kubernetes/cloud-provider-openstack/issues/1328

https://github.com/kubernetes/cloud-provider-openstack/pull/1375

[jichenjc]

um... not sure fully understand this , but follow your [0] makes me think you want to do on ExternalRouterIPs then read your description again seems you want to work on ExternalNetworkID which are 2 different concepts to me

and I guess you want to work on ExternalNetworkID then yes ,provide a subnet ID seems reasonable (but will openstack use 2nd subnet if 1st used up so anyway 2nd subnet will be used later ??)

and yes, I think it should be good for us to add such param, in case not provided, go with "" should be fine

[raildo]

Probably, I pointed out to the wrong code link on [0] when I was trying to find the related code, but you're right on the second statement. When we have a deployment multiple subnets on the external network, I'm looking forward to be able choose on which subnet I want the cluster to grab a Floating IP, that's my suggestion on including that new param OPENSTACK_EXTERNAL_SUBNET_ID (or any other similar name that fits for everyone).

Also I'm ok with, as you mentioned on your comment, if not provided, go with "" on it.

[jichenjc]

/assign

ok, let me give a try

[raildo]

Cool! Thank you, I'm able to test it, if needed, in a real openstack cloud before we merged it. Just let me know :)

[jichenjc]

sorry for the confusion, I read the doc and code again and looks like I misunderstand the code a little bit at beginning in your case [0] ,actually that's logic only when [1] is True

so have you tried openStackCluster.Spec.ExternalRouterIPs.Subnet.UUID to your subnet ID directly thus the UUID will indicate the subnet you choose?

[0] https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/pkg/cloud/services/networking/router.go#L168 [1] https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/pkg/cloud/services/networking/router.go#L158

[raildo]

I haven't tried changing this ID directly. Is there a way to do it using the external template, or should I change the openStackCluster.Spec.ExternalRouterIPs.Subnet.UUID directly after the clusterctl generate? I can give it a shoot here and see how it goes. I can poke you on slack if you want to as well, if you prefer.

[jichenjc]

directly after the clusterctl generate

I think you can give a try after generate, we use yaml file to apply and that clusterctl is just for simple creation sure, ping me any time and reply you when I see it :)

[apricote]

@jichenjc Are you still working on this?

[jichenjc]

@apricote check above comments, I think existing way can achieve the functions so I didn't submit a PR waiting for validation on the way proposed above now

[raildo]

Hey all, sorry for the late response. Unfortunately I was not able to uses the openStackCluster.Spec.ExternalRouterIPs.Subnet.UUID during the previous tests. I'm not sure if someone else can tests it as well, or if you guys want we can pair or try to setup some test env to give it a try.

[jichenjc]

ok, I will try this later when got some time, fully occupied now :(

[jichenjc]

opened https://github.com/gophercloud/gophercloud/issues/2425 for subnet ID into floating ip creation

for now, can you help to use APIServerFloatingIP as workaround so that you can select from 2nd subnet on the floating ip specificly?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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.