Incorrect fix for ObjectMeta issue in CloudStackMachineTemplateResource in v1beta3 API

[hrak]

/kind bug

What steps did you take and what happened: [A clear and concise description of what the bug is.]

The v1beta3 API version bump was created to solve an issue related to creationTimestamp being null in a serialization of a CloudStackMachineTemplate resource (See related issues #166 #176 #237)

The solution applied here is to completely remove the ObjectMeta field from the CloudStackMachineTemplateSpec struct, but this is not the right fix for this issue, and against API conventions.

The main problem is that in v1beta1 and v1beta2, CloudStackMachineTemplateSpec is defined as this:

type CloudStackMachineTemplateResource struct {
    // Standard object's metadata.
    // More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
    // +optional
    // +nullable
    ObjectMeta metav1.ObjectMeta     `json:"metadata,omitempty"`
    Spec       CloudStackMachineSpec `json:"spec"`
}

while it should be defined as this:

type CloudStackMachineTemplateResource struct {
    // Standard object's metadata.
    // More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
    // +optional
    ObjectMeta clusterv1.ObjectMeta  `json:"metadata,omitempty"`
    Spec       CloudStackMachineSpec `json:"spec"`
}

Note the metav1 vs clusterv1 and removal of nullable. I've verified this in various other CAPI infra providers (CAPA, CAPZ).

clusterv1.ObjectMeta has been specifically introduced in CAPI to address this issue with creationTimestamp. See the elaborate comment at https://github.com/kubernetes-sigs/cluster-api/blob/36e9abaa070c0bb0dfbfc81d2e2795b245797db5/api/v1beta1/common_types.go#L271

What did you expect to happen:

No complete removal of ObjectMeta in CloudStackMachineTemplateResource.

[hrak]

I suggest we fix this before the release of 0.4.9 (since this is the sole reason we bumped the API), and also consider including #328 (to make the API version bump worthwhile) and #329 (cc @g-gaston )

[g-gaston]

Cc @vignesh-goutham since he was leading the api change

[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