api: output/v1alpha1 depends on kubeadm/v1beta2

[neolit123]

preparing some of the changes for v1beta3, i realized that we have a problematic dependency that have slipped trough review:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/apis/output/v1alpha1/types.go#L32

context: kubeadm has two API groups ATM - output (for machine readable output) and kubeadm (for the kubeadm config API).

embedding of a WIP API in another WIP API is always problematic.

if we continue doing this embedding it forces us to either:

• keep pinning to v1beta2 until the output group graduates (this of course is absurd)
• release a new version in the output group every time the kubeadm group releases a new version or when we are about to remove the pinned version. this is far from ideal too, as it is just noise. [*]

possible solutions:

1. just do [*] before removing v1beta2
2. release output/v1alpha2 that embeds a complete copy of bootstraptoken and bootstraptokenstring:
   https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/cmd/kubeadm/app/apis/kubeadm/v1beta2/types.go#L226-L246
   this duplication is also asking for trouble.
3. move bootstraptoken and bootstraptokenstring to a new API group called "bootstraptoken" and version it v1 (v1 because it hasn't changed in a long time!), make both the new kubeadm API v1beta3 and a new output group v1alpha2 import it. conversion will be likely sketchy but doable.

3 feels like the right thing to do.
i was thinking of another way to handle this by treating BootstrapToken in the output API as runtime.Object, but given this is also in the public API users would need helpers to marshal / unmarshal it.

something else to remind here is that historically we wanted to move the bootstraptoken* API to component-base but this idea was rejected.

added milestone v1.22, but we can technically delay this decision until kubeadm/v1beta2 is removed.

cc @fabriziopandini

---

tasks:

1.22:

• move bootstraptoken and bootstraptokenstring to a new API group called "bootstraptoken" and version it v1 (v1 because it hasn't changed in a long time!) make the new kubeadm API v1beta3 use it:
  kubeadm: decouple the bootstraptoken API from the kubeadm API kubernetes#102964

1.23:

• add output/v1alpha2 and make it import bootstraptoken/v1. conversion will be likely sketchy but doable.
  mark output/v1alpha1 as deprecated.
  kubeadm: add a new output/v1alpha2 API; deprecate output/v1alpha1 kubernetes#105295

1.24:

• remove output/v1alpha1
  kubeadm: remove the deprecated output/v1alpha1 API kubernetes#107468

[wangyysde]

/cc @wangyysde

[danishprakash]

@neolit123 I'd like to work on this, hope that's ok.

[neolit123]

@danishprakash

let's hold on this work until we make a clearer decision whether we want to proceed with it for 1.22.
please have a look at some of our other tickets with help-wanted labels.

[neolit123]

i did some investigation recently and with that completed the part about:

move bootstraptoken and bootstraptokenstring to a new API group called "bootstraptoken" and version it v1 (v1 because it hasn't changed in a long time!), make both the new kubeadm API v1beta3 and a new output group v1alpha2 import it. conversion will be likely sketchy but doable.

kubernetes/kubernetes#102964

we should keep this issue open, until we deprecate / remove v1beta2:
at that point we should:

• release a new output API version and make it use bootstraptoken/v1.
• remove the API version output/v1alpha2 that embeds v1beta2.BootstrapToken.

v1beta2 is not yet deprecated. we might do it in v1.23:
#2459

removing it will take +3 releases after that.