Tracking issue for v1Beta2

[sbueringer]

Tracking issue for the work to bump to v1beta2.

This is very incomplete as of now, but we can already use it to collect tasks.

• !!! Go through Cluster API umbrella issues and check which tasks are applicable to CAPV as well

• Create v1beta2 CAPV API as a mirror copy of CAPV v1beta1 API (prior art ⚠️ Add v1beta2 types cluster-api#12037)

  • Implement conversions (no op at this stage)
  • Change all the infrav1 imports to use v1beta2

• Ensure we use clusterv1.MachineAddress instead of corev1.NodeAddress in VSphereMachineStatus

• Move v1beta2 conditions top level, v1beta1 conditions to deprecated (prior art ⚠️ Promote v1beta2 conditions cluster-api#12066)

  • Fix conversions

• Rename conditions const (prior art ⚠️ conditions: add V1Beta1 suffix and remove V1Beta2 suffix from condition types and reasons in v1beta2 packages cluster-api#12091)

• Implement changes for the v1beta2 contract (prior art ⚠️ Add initialization to Cluster status cluster-api#12098, ⚠️ Add initialization to Machine Status cluster-api#12101)

  • Add initialization struct, move ready into it
  • Fix conversions
  • Annotate CAPD CRDs to declare they are implementing the v1beta2 contract

• Stop using v1beta1 conditions, old replica counters, failureReason and failureMessage in controllers

• Migrate E2E tests to v1beta2

• ⚠️ Remove DefaulterRemoveUnknownOrOmitableFields mutating webhook option cluster-api#12231

• Migrate vcsim to use v1beta2 when bumping to CAPI v1.14 / having minimum CAPI version v1.11 in upgrade tests/vsphere.yaml

  • We can't upgrade vcsim during tests because restarts would kill the vcsim instance and loose data during tests. As long as we run a test using CAPI < v1.11, we can't reconcile based on v1beta2 because the resources simply don't exist yet.

Misc:

• Consider using clusterv1.MachineAddress instead of corev1.NodeAddress

[PatrickLaabs]

Greetings everyone,
I was checking, if I might help on any task on this.

The last one "Consider using clusterv1.MachineAddress instead of corev1.NodeAddress" seemed reasonable for me, to start with.

Just a quick adjusting to the VSphereMachineStatus struct:

// import:
VSphereMachineStatus
+       clusterv1 "sigs.k8s.io/cluster-api/api/core/v1beta2"

// VSphereMachineStatus struct
-       Addresses []corev1.NodeAddress `json:"addresses,omitempty"`
+       Addresses []clusterv1.MachineAddress `json:"addresses,omitempty"`

and a make generate-go-deepcopy changed these lines for the zz_generated.deepcopy.go file:

-               *out = make([]v1.NodeAddress, len(*in))
+               *out = make([]v1beta2.MachineAddress, len(*in))

And I just ran make test afterwards.
I am not quite sure, if this covers what we want?

[sbueringer]

Thx for looking into this. We are not planning to move to v1beta2 in this release as we don't have the bandwith for it.

[k8s-triage-robot]

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

This bot triages un-triaged 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:

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

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

/lifecycle stale

[sbueringer]

/remove-lifecycle stale