✨ Implement CAPI v1beta2 contract support with api/v1beta2

[bnallapeta]

/kind feature

Describe the solution you'd like
Implement full CAPI v1beta2 contract support by creating a new api/v1beta2 API version with required breaking changes.

Background
CAPO v0.13.2 (?) reverted to v1beta1 contract. v0.15 will properly implement v1beta2.

Tasks

API Changes:

• Create api/v1beta2/ with breaking changes:
  • Change conditions: clusterv1.Conditions → []metav1.Condition
  • Remove deprecated fields: status.ready, status.failureReason, status.failureMessage
  • Update FailureDomains if needed
• Update all v1beta1 resources: OpenStackCluster, OpenStackMachine, OpenStackClusterTemplate, OpenStackMachineTemplate
• Run make generate to generate deepcopy, CRDs, etc.

Conversion & Webhooks:

• Implement conversion webhooks (v1beta1 ↔ v1beta2)
• Update validation/defaulting webhooks for v1beta2
• Update CRD labels: cluster.x-k8s.io/v1beta2: v1beta2

Controllers & Templates:

• Update controllers to use conditions instead of deprecated fields
• Update all cluster templates in templates/ to v1beta2
• Update metadata.yaml to claim v1beta2 contract

Documentation & Testing:

• Create migration guide: docs/book/src/topics/crd-changes/v1beta1-to-v1beta2.md
• Unit tests for conversion webhooks
• E2E tests with CAPI v1.11+ (v1beta2 contract)
• Upgrade tests (v1beta1 → v1beta2)

[bnallapeta]

/assign

[nikParasyr]

My ideas are mostly around tidying-up/consistency.
I'm not sure whether we should include them in this new api version since we might want to get v1beta2 compatibility asap.
I can allocate some time to work on my proposals but it will require the base of v1beta2 to be in-place.

---

1. OSM: Update flavor to follow id/filter standard:

Current the OSM allows the following:

Kind: OpenStackMachine
...
spec:
  ...
  flavor: <Name of flavor>
  flavorID: <ID of flavor>
  ...

This should be updated to the one below so that its consistent with all other fields:

Kind: OpenStackMachine
...
spec:
  ...
  flavor:
    ID: <ID of flavor>
    Filter:
      Name: ...
      <other list options of flavor>
  ...

---

2. OSC: Group network related fields under managedNetwork

For most of the resources that capo creates we have a field with managedXYZ. This is not the case for network, so:

Kind: OpenStackCluster
...
spec:
  ...
  disablePortSecurity: false/true
  networkMTU: <int>
  ...

Should be grouped into:

Kind: OpenStackCluster
...
spec:
  ...
  managedNetwork:
    disablePortSecurity: false/true
    mtu: <int>
  ...

---

3. OSC: Group router related fields under managedRouter

For most of the resources that capo creates we have a field with managedXYZ. This is not the case for router, so:

Kind: OpenStackCluster
...
spec:
  ...
  externalRouterIPs:
  - fixedIP: XYZ
    subnet:
      filter:
        name: ZYX
  ...

Should be grouped into:

Kind: OpenStackCluster
...
spec:
  ...
  managedRouter:
    externalIPs:
    - fixedIP: XYZ
      subnet:
        filter:
          name: ZYX
  ...

---

4. OSC: 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...
  ...

I will need to spend some time to see how the above should be best group because for each one of them I need to clarify:

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

---

[bnallapeta]

All these are good improvements. But I agree with your initial statement. First, we need the base of v1beta2 ready without changing any fields. Just migrate. And then, we could work on these in individual issue/PRs. Feel free to create separate issues for each one so that we don't lose track.