Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

release v1beta4 #2890

Open
23 of 26 tasks
chendave opened this issue Jun 9, 2023 · 25 comments
Open
23 of 26 tasks

release v1beta4 #2890

chendave opened this issue Jun 9, 2023 · 25 comments
Assignees
@neolit123
Labels
kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/design Categorizes issue or PR as related to design. kind/tracking-issue priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Milestone
v1.31

Comments

@chendave
Copy link
Member

chendave commented Jun 9, 2023 •
edited by neolit123

(edited by neolit123)

general action items:

  • finalize v1beta4 tasks;
    • document the v1beta4 changes set and prepare a release note
    • move v1beta4 to the first element (highest priority) in api/kubeadm/scheme/scheme.go#AddToScheme()
    • support for v1beta4 'config migrate' and 'config validate'
  • kubeadm: enable the v1beta4 API kubernetes#125029
  • Start using v1beta4 in kinder e2e tests

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
Copy link
Member Author

chendave commented Jun 9, 2023

ref: kubernetes/enhancements#970 (comment)

@chendave
Copy link
Member Author

chendave commented Jun 9, 2023

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

@chendave
Copy link
Member Author

chendave commented Jun 9, 2023

ref: kubernetes/kubernetes#114534 (comment)

@chendave
Copy link
Member Author

chendave commented Jun 9, 2023

/assign

@neolit123 neolit123 added kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/design Categorizes issue or PR as related to design. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. labels Jun 9, 2023
@neolit123 neolit123 added this to the v1.29 milestone Jun 9, 2023
@neolit123
Copy link
Member

neolit123 commented Jun 9, 2023 •
edited

please include all labeled issues
kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API
(even if some are a bit vague / not actionable)

@neolit123
Copy link
Member

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
Copy link
Member Author

chendave commented Jun 9, 2023

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
Copy link
Member Author

chendave commented Jun 9, 2023

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
Copy link
Member

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

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

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
Copy link
Member Author

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
Copy link
Member

pacoxu commented Jun 12, 2023

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
Copy link
Member

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
Copy link
Member Author

@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
Copy link
Member

/cc

@SataQiu
Copy link
Member

SataQiu commented Jun 12, 2023

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
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member Author

chendave commented Jun 14, 2023 •
edited

@neolit123 thanks for bringing this to the sig meeting!

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

sure, will do.

@fabriziopandini
Copy link
Member

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
Copy link
Member

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
Copy link
Member Author

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 neolit123 changed the title v1beta4 candidate list release v1beta4 Jun 20, 2023
@neolit123 neolit123 mentioned this issue Jun 20, 2023
Merged
@neolit123
Copy link
Member

boilerplate PR
kubernetes/kubernetes#118762

@chendave chendave mentioned this issue Jun 26, 2023
Merged
@SataQiu SataQiu mentioned this issue Jun 26, 2023
Merged
@neolit123 neolit123 mentioned this issue Jun 28, 2023
Merged
@neolit123
Copy link
Member

@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

@chendave chendave mentioned this issue Jul 2, 2023
Closed
@neolit123 neolit123 mentioned this issue Jul 2, 2023
Closed
This was referenced Jul 10, 2023
Merged
Open
Merged
Merged
Merged
@SataQiu SataQiu mentioned this issue Jul 15, 2023
Merged
@chendave chendave mentioned this issue Jul 22, 2023
Closed
3 tasks
@pacoxu
Copy link
Member

pacoxu commented Aug 5, 2023

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
Copy link
Member Author

chendave commented Aug 8, 2023 •
edited

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.

@neolit123 neolit123 modified the milestones: v1.29, v1.30 Nov 1, 2023
@neolit123 neolit123 mentioned this issue Dec 29, 2023
Merged
@prezha prezha mentioned this issue Jan 7, 2024
Merged
11 tasks
@neolit123 neolit123 mentioned this issue Jan 9, 2024
Closed
@pacoxu pacoxu mentioned this issue Jan 31, 2024
Closed
@calvin0327 calvin0327 mentioned this issue Feb 1, 2024
Merged
@yankay yankay mentioned this issue Feb 20, 2024
Open
@neolit123 neolit123 mentioned this issue Feb 29, 2024
Merged
@neolit123 neolit123 modified the milestones: v1.30, v1.31 Apr 5, 2024
@neolit123 neolit123 mentioned this issue Apr 22, 2024
Merged
@neolit123 neolit123 assigned neolit123 and unassigned chendave Apr 30, 2024
@neolit123 neolit123 mentioned this issue May 30, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@neolit123 neolit123

Labels
kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/design Categorizes issue or PR as related to design. kind/tracking-issue priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Projects
None yet
Milestone
v1.31
Development

No branches or pull requests
6 participants
@neolit123 @pacoxu @fabriziopandini @chendave @SataQiu @ruquanzhao