search

kubernetes / kubeadm

Aggregator for issues filed against kubeadm
Apache License 2.0
3.76k stars 716 forks source link

release v1beta4 #2890

Closed chendave closed 2 months ago

chendave commented 1 year ago

(edited by neolit123)

general action items:

list of features:

There are already PR ready for the first three, others either need the further discussion or need someone's commitment to own.

BREAKING change

Design is not clear at the moment

chendave commented 1 year ago

ref: https://github.com/kubernetes/enhancements/issues/970#issuecomment-1467580054

chendave commented 1 year ago

@neolit123 @SataQiu @pacoxu would like to hear your feedback on this. Is this list enough for v1beta4?

chendave commented 1 year ago

ref: https://github.com/kubernetes/kubernetes/pull/114534#issuecomment-1584268650

chendave commented 1 year ago

/assign

neolit123 commented 1 year ago

please include all labeled issues https://github.com/kubernetes/kubeadm/labels/kind%2Fapi-change (even if some are a bit vague / not actionable)

neolit123 commented 1 year ago

i've added this to .29. i think if this api code work is to happen it should be at the start of a release cycle. but perhaps we can get all the planning done in .28. what do people think?

chendave commented 1 year ago

please include all labeled issues

I hope I haven't miss anything, the list is updated.

(even if some are a bit vague / not actionable)

Haven't got the chance to go through each of them, but I will evaluate each of them in the near future.

chendave commented 1 year ago

i think if this api code work is to happen it should be at the start of a release cycle. but perhaps we can get all the planning done in .28

+1. we can also get some of them implemented within the time frame of .28 after the scope if finalized.

neolit123 commented 1 year ago

i was thinking that if we want to work on an api for multiple releases, we could try this:

the tricky part would be getting kubeadm to agree on this wip status.

in this approach, a single release note must be used listing all changes when we are ready - i.e. all api changes must go without release notes.

reminder - we should not iterate new features over a released api, because it causes pain for consumers like capi. ideally, an api should be a released, locked feature set.

chendave commented 1 year ago

add the new api boilerplate / clone v1beta3 prevent the users from using it via cli / wip errors in a few key places

+1, I believe we can start this in .28 release, and part of features could be added in .28 as well, otherwise, it would be a little rush for .29 release. We will definitely has some warning for v1beta4 before the official release.

pacoxu commented 1 year ago

reminder - we should not iterate new features over a released api, because it causes pain for consumers like capi. ideally, an api should be a released, locked feature set.

Should we include the CAPI team and other consumers in this topic to get more feedback?

neolit123 commented 1 year ago

reminder - we should not iterate new features over a released api, because it causes pain for consumers like capi. ideally, an api should be a released, locked feature set.

Should we include the CAPI team and other consumers in this topic to get more feedback?

we could email the sig mailing list.

chendave commented 1 year ago

@neolit123 @pacoxu I am currently triage all those requirements, will send a summarization to the mailing list or join the sig community meeting for the head-ups and ask for review comments.

ruquanzhao commented 1 year ago

/cc

SataQiu commented 1 year ago

work on an api for multiple releases

We can introduce the v1beta4 API, but not register it into the Scheme, prevent users to use it. https://github.com/kubernetes/kubernetes/blob/18d05b646d09b2971dc5400bc288062b0414e8cf/cmd/kubeadm/app/apis/kubeadm/scheme/scheme.go#L42-L46

chendave commented 1 year ago

We can introduce the v1beta4 API, but not register it into the Scheme, prevent users to use it.

that's indeed a good suggestion, thanks @SataQiu !

neolit123 commented 1 year ago

FYI. in yesterday's Sig meeting we discussed kubeadm's v1beta4 plan. @fabriziopandini requested that we tag in the above list what is a [BREAKING] change. one example is allowing duplicate extraArgs. please check if there is anything else.

https://docs.google.com/document/d/1Gmc7LyCIL_148a9Tft7pdhdee0NBHdOfHS1SAF0duI4/edit?usp=drivesdk

we also discussed whether this should be a v1 or a v1beta4. my vote was to gather motivation from the kubelet which is moving to v1. perhaps v1beta4 should be our last beta. ideally, this means we should do all the planned breaking changes in this beta4. otherwise we need to plan v2 after the v1.

chendave commented 1 year ago

@neolit123 thanks for bringing this to the sig meeting!

we tag in the above list what is a [BREAKING] change

sure, will do.

fabriziopandini commented 1 year ago

thanks for adding [breaking]; it will echo yesterday discussion today at the CAPI office hours and report back feedback/ask people to provide feedback directly here

neolit123 commented 1 year ago

i can try sending the boilerplate pr for v1beta4 later today. copy v3 -> v4, essentially.

work on an api for multiple releases

We can introduce the v1beta4 API, but not register it into the Scheme, prevent users to use it. https://github.com/kubernetes/kubernetes/blob/18d05b646d09b2971dc5400bc288062b0414e8cf/cmd/kubeadm/app/apis/kubeadm/scheme/scheme.go#L42-L46

i was thinking about this. it can work partially as long as we make the right changes in the internal api. but it will not work for breaking changes e.g. removing the ecdsa FG.

we may have to add the api changes first, keep the api out of the scheme, think when to add business logic, once ready for release add the api in the scheme, but drop api changes without business logic.

chendave commented 1 year ago

we may have to add the api changes first, keep the api out of the scheme, think when to add business logic, once ready for release add the api in the scheme, but drop api changes without business logic.

SGTM, we can have the boilerplate as the first commit and the api change as an incremental commit.

neolit123 commented 1 year ago

boilerplate PR https://github.com/kubernetes/kubernetes/pull/118762

neolit123 commented 1 year ago

@ruquanzhao since you have this task:

Allow overwrite KubeletRunDirectory when init/join Allow overwrite KubeletRunDirectory when init/join #2104

i will take the other one assigned to you:

handling of extraArgs which are allowed multiple times

pacoxu commented 1 year ago

Too many tasks are tracked here. Should we use a simple GitHub board to track v1beta4-related things?

https://github.com/orgs/kubernetes/projects

chendave commented 1 year ago

thanks @pacoxu for the info! I am +1 to create the board.

Most important features which need some attention now is:

Anything else should not hard to address, e.g. enable the v1beta4 in code base, ignore the errors should be align with other flag/config etc.

pacoxu commented 4 months ago

https://github.com/kubernetes/kubernetes/pull/125029 is merged for v1.31.

neolit123 commented 2 months ago

closing this one. thanks everyone. let's track bugs / feedback in separate new tickets.