New API version: v1alpha3

[olemarkus]

I want to restart the new API version discussion that we had in #9178

As I think we'll do a number of changes, an umbrella issue is appropriate and this one should serve as that.

I want v1alpha3 to not be roundtrip-compatible with v1alpha2. However, both should roundtrip with the unversioned spec without data loss. This is the same that we see k/api doing.

This means we need to use a lot of conversion functions to convert between the versioned and unversioned specs.

I want the unversioned spec to contain what templates etc require. That means the unversioned spec can contain fields that the versioned do not, but that nodeup add as required. This can replace some of the template functions we have.

A consequence of this is that validation need to happen on each of the versioned specs, not the unversioned one.

We should also add support for versioned get ig/cluster so users can choose which one to export and modify.

To get started we need to:

• [ ] Add a version flag to kops get so users can choose between v1alpha2 and v1alpha3
• [ ] Copy v1alpha2 to v1alpha3
• [ ] Migrate validation logic to use v1alpha2 instead of unversioned spec (move validation package as sub package to v1alpha2?)
• [ ] Register the v1alpha3 api version if a given feature gate has been set

[hakman]

Spotinst uses machineType for a "," separated instance types list, which is not ideal. mixedInstancesPolicy also has instances field for an instance types list. I think going forward machineType should be a list, to have a single place to keep such info.

[johngmyers]

We need to fix #9229 before we can do any apiversion changes.

[johngmyers]

We are way beyond being able to use the alpha rules. The next apiversion needs at least beta guarantees. We need to treat v1alpha2 as at least beta, if not stable.

I would say that we do not need to roundtrip fields that either cause validation to fail or have no effect on behavior.

[olemarkus]

I think we can promote v1alpha2 to v1. It just seems silly to have a stable product use alpha API versions that are really of v1 quality.

I think perhaps what we are discussing is v2alpha1.

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[hakman]

/remove-lifecycle rotten

[hakman]

/lifecycle frozen