Should we drop support for kubeadm v1beta1 types?

[fabriziopandini]

CABPK & KCP in the v1alpha4 branch support kubeadm API v1beta1, v1beta2 and soon v1beta3 (#4445).

This issue is about discussing the option to drop support for kubeadm v1beta1 types, which practically means that capi v1alpha4 cannot be used to create Kubernetes clusters < v1.15.

Now kubeadm v1.15 is N-6 as of today, this makes such release out of the skew support being discussed in #4464; however, given that this is not yet confirmed, I have opened a separated issue to see if we can get this cleanup moving.

/kind cleanup

@vincepri @CecileRobertMichon @sbueringer

[vincepri]

I'm ok dropping support in v0.4

[sbueringer]

+1 from me too.
Main argument for me is that supporting n-6 (and it will be a lot more at the time of the release and over the lifetime of v0.4.0) is not sustainable.

[CecileRobertMichon]

Main argument for me is that supporting n-6 (and it will be a lot more at the time of the release and over the lifetime of v0.4.0) is not sustainable.

+1 from me as well with the same reasoning

[vincepri]

/milestone v0.4

[vincepri]

/kind release-blocking

[vincepri]

/help

[k8s-ci-robot]

@vincepri:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help

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.

[gab-satchi]

/assign

[vincepri]

/lifecycle active

[fabriziopandini]

/milestone next
This should wait after we remove v1alpha3 API (v1alpha3 API is embedding kubeadm v1beta1 types 😞 )

[k8s-ci-robot]

@fabriziopandini: The provided milestone is not valid for this repository. Milestones in this repository: [Next, v0.3, v0.4]

Use /milestone clear to clear the milestone.

In response to this:

/milestone next
This should wait after we remove v1alpha3 API (v1alpha3 API is embedding kubeadm v1beta1 types 😞 )

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.

[vincepri]

Could we add a deprecation notice to the package at least?

[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

[neolit123]

kubeadm v1beta1 was already removed in 1.22.
i will propose v1beta2 to be deprecated in 1.24 and it will be removed in e.g. 3+ releases.

[neolit123]

/remove-lifecycle rotten

[sbueringer]

/milestone next
This should wait after we remove v1alpha3 API (v1alpha3 API is embedding kubeadm v1beta1 types 😞 )

Based on this and the current state of the v1beta1 discussion, we will have to wait until the next version after v1beta1 (I guess v1beta2) to drop this.

[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

[fabriziopandini]

/lifecycle frozen

[sbueringer]

As discussed in the backlog grooming on 11th February, we'll close this issue for now. We can only drop the kubeadm v1beta1 types once we drop our v1alpha3 types (as they are embedded there).

(we will drop them then)

/close

[k8s-ci-robot]

@sbueringer: Closing this issue.

In response to this:

As discussed in the backlog grooming on 11th February, we'll close this issue for now. We can only drop the kubeadm v1beta1 types once we drop our v1alpha3 types (as they are embedded there).

(we will drop them then)

/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.