🐛 Define subnetID on LB member when networks differ

[nikParasyr]

What this PR does / why we need it:
Define subnetID on ovn LB member creation when the user is using different networks for the cluster and the loadbalancer

Which issue(s) this PR fixes:
Fixes #2790

Special notes for your reviewer:
In general I have some concerns with the approach, would like input from your side:

1. I'm using openStackCluster.Status.APIServerLoadBalancer.LoadBalancerNetwork.ID. While working on this i noticed that the field is not always populated ( related PR )
2. I'm checking whether the provider is "ovn", amphora also supports different subnet IDs (although i've never seen it in action). I could drop this check but it would require point 1 being resolved ( in theory we could always set subnetID on member create opts == openStackCluster.Status.Network.Subnets[0].ID -- see point 3 )
3. The subnetID is set to openStackCluster.Status.Network.Subnets[0].ID. A control-plane machine can be attached to different subnets ( if OSM.spec.ports. are defined ). I couldnt find a way to get the subnetID from the spec though as a user can define just a spec.ports[0].network.id (or a filter) and OSM.status doesn't provide info on subnetID. So the assumption is that the control-plane machine is using the cluster subnet.

TODOs:

• squashed commits
• if necessary:
  • includes documentation
  • adds unit tests

/hold

[netlify]

✅ Deploy Preview for kubernetes-sigs-cluster-api-openstack ready!

Name	Link
🔨 Latest commit	d7b456f
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-sigs-cluster-api-openstack/deploys/6909ef249815eb0007e548c1
😎 Deploy Preview	https://deploy-preview-2799--kubernetes-sigs-cluster-api-openstack.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[k8s-ci-robot]

Hi @nikParasyr. Thanks for your PR.

I'm waiting for a github.com member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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-sigs/prow repository.

[lentzi90]

/ok-to-test

[nikParasyr]

/retest

[bnallapeta]

@nikParasyr Thanks for the fix! I am not sure if checking for each provider is really optimal; especially in the long run.

Currently, if I am not wrong, in Octavia, member SubnetID is optional and can be provided. If it’s omitted, Octavia will infer a suitable subnet from the member port’s network. However, in cross-network scenarios (e.g., VIP network != member network), OVN requires an explicit SubnetID for the member to be created correctly. Amphora accepts SubnetID too, so providing it is generally safe.

I can see two options that could be provider-agnostic.

1. Always set SubnetID based on the member’s actual subnet
2. Set SubnetID whenever the VIP network differs from the member’s network

Either path avoids per-provider conditionals and works even when the default provider is OVN without being specified in the spec. Let me know what you think.

cc @lentzi90

[lentzi90]

With #2798 merged, can we drop the check for ovn? I think that would be good to do. The other check for LB vs cluster network ID is good IMO. You are right that we could just unconditionally set the ID but I think there is a point also relying on the defaults as we have been doing so far.

[nikParasyr]

With #2798 merged, can we drop the check for ovn? I think that would be good to do. The other check for LB vs cluster network ID is good IMO. You are right that we could just unconditionally set the ID but I think there is a point also relying on the defaults as we have been doing so far.

Done.

[lentzi90]

/approve

[bnallapeta]

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bnallapeta, lentzi90

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:

• OWNERS [lentzi90]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[lentzi90]

/hold cancel