:sparkles: v1beta2 Group apiServer related fields on OpenStackCluster

[nikParasyr]

/kind feature

Group api server related fields

So currently we have a lot of fields for the apiServer that are not grouped.

Kind: OpenStackCluster
...
spec:
  ...
  apiServerFixedIP: string
  apiServerFloatingIP: string
  apiServerPort: string
  disableAPIServerFloatingIP: bool
  apiServerLoadBalancer:
    ...lots of things here...
  ...

We need to clarify how the above should be best group because each one of them:

• may apply only for the managed LB <- should be part of the apiServerLoadBalancer object
• may apply only when LB is disabled <- need to think if they can be grouped on a seperateObject or not
• may apply on both <- need to think if we should seperate them or not etc

Implementation should be done after core v1beta2 is implemented in #2895

[nikParasyr]

/assign

[nikParasyr]

After going through the code in:

• https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/controllers/openstackcluster_controller.go#L876
• https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/pkg/cloud/services/loadbalancer/loadbalancer.go#L82
• https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/controllers/openstackmachine_controller.go#L694

I think we support 3 scenarios:
a. openStackCluster.Spec.APIServerLoadBalancer.IsEnabled() => Uses all the above mentioned fields (port for listeners, fixedIP for LB VIP, floatingIP for LB FIP, disableFloatingIP to not attach a FIP)
b. LB is disabled but apiServerFloatingIP and externalNetwork are set => Uses apiServerFloatingIP to create the endpoint and also to attach it to a control-plane osm
c. LB, apiServerFloatingIP and externalNetwork are disabled. apiServerFixedIP is set => Uses apiServerFixedIP to create the endpoint, leaves the rest to the user

(apiServerPort is used on all the scenarios above to set the endpoint)

Based on the above I would propose the following 2 options:

---

Option 1:
Move everything into a apiServer object:

...
spec:
  ...
  apiServer:
    port: string            <= previous apiServerPort
    fixedIP: string         <= previous apiServerFixedIP
    floatingIP: string      <= previous apiServerFloatingIP
    disableFloatingIP: bool <= previous disableAPIServerFloatingIP
    managedLoadBalancer:    <= previous apiServerLoadBalancer
      ...same fields as before...
  ...

---

Option 2:
Split into 2 seperate objects (mutually exclusive through api validations) and duplicate:

...
spec:
  ...
  apiServer:                <= might need to find a better name for this
    port: string            <= previous apiServerPort
    fixedIP: string         <= previous apiServerFixedIP
    floatingIP: string      <= previous apiServerFloatingIP
    disableFloatingIP: bool <= previous disableAPIServerFloatingIP

  managedAPIServerLoadBalancer: <= previous apiServerLoadBalancer
    port: string            <= previous apiServerPort
    fixedIP: string         <= previous apiServerFixedIP
    floatingIP: string      <= previous apiServerFloatingIP
    disableFloatingIP: bool <= previous disableAPIServerFloatingIP
    ...same fields as before, maybe remove the enabled part...

---

I don't have a strong preference. My opinion is:

• option 1: easier to implement, closer to v1beta1, no duplication
• option 2: more work and bigger change, duplication introduced but I think it will make it more clear to the users and also our code a bit more clean

[lentzi90]

I quite like option 1 but so far no strong preference.
Maybe @mdbooth, @EmilienM and @mandre have some opinions?