ResetConfiguration and UpgradeConfiguration API definition

[chendave]

Enhancement Description

• One-line enhancement description (can be used as a release note): Add UpgradeConfiguration/ResetConfiguration API types for kubeadm upgrade and kubeadm reset respectively.
• Kubernetes Enhancement Proposal: https://docs.google.com/document/d/1R4zLtgDadNM8_N2VzS0DI2mADcYmkyJ3L7lJVpbyZsA (TO be updated)
• Discussion Link: add UpgradeConfiguration/ResetConfiguration API types kubeadm#2489
• Primary contact (assignee): @chendave
• Responsible SIGs: sig-cluster-lifecycle
• Enhancement target (which target equals to which milestone):
  • Alpha release target (x.y): maybe 1.26 or 1.27
  • Beta release target (x.y): 1.28
  • Stable release target (x.y): 1.29
• Alpha
  • KEP (k/enhancements) update PR(s):
  • Code (k/k) update PR(s):
  • Docs (k/website) update PR(s):

Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.

[chendave]

/sig sig-cluster-lifecycle
/assgin

[k8s-ci-robot]

@chendave: The label(s) sig/sig-cluster-lifecycle cannot be applied, because the repository doesn't have them.

In response to this:

/sig sig-cluster-lifecycle
/assgin

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[chendave]

/sig cluster-lifecycle
/assign

[neolit123]

@chendave we can use the existing issue / KEP:
#970

[chendave]

@neolit123 I am thinking how to re-use the existing KEP: https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/970-kubeadm-config

That KEP is quite high level, consolidate what we have in this doc: https://docs.google.com/document/d/1R4zLtgDadNM8_N2VzS0DI2mADcYmkyJ3L7lJVpbyZsA looks a little weird, if we follow the style, we won't get much detail to discuss in the KEP.

How about create a separate a KEP and link that to the 970?

[neolit123]

that is true, i guess.

so, historically we did not add struct / field details in the kubeadm config KEP and i think we should keep it that way.
if we are about to introduce v1beta4 we can just enumerate what changes are being made, similarly to how we did for v1beta3:
https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/970-kubeadm-config#v1beta3

adding reset/upgrade config would be one of the chanegs.
details can remain in the google doc and k/kubeadm tracking issue.

@SataQiu @pacoxu WDYT?
i think we should close this and avoid having a new k/e issue / KEP.

[pacoxu]

A update to #970 would be OK.
So that we can know what changes in each version, like v1beta3\v1beta4.

Agree.

[chendave]

I am fine with each one.

[chendave]

details can remain in the google doc and k/kubeadm tracking issue.

+1

Let's continue to the discuss in the google doc, I will close this one until there is need to re-open this.

/close

[k8s-ci-robot]

@chendave: Closing this issue.

In response to this:

details can remain in the google doc and k/kubeadm tracking issue.

+1

Let's continue to the discuss in the google doc, I will close this one until there is need to re-open this.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.