Need clarification: KEP stages and transitions #2960
Comments
k8s-ci-robot
added
the
needs-sig
|
/sig release |
k8s-ci-robot
added
sig/release
|
cc: @kubernetes/sig-release @kubernetes/enhancements |
k8s-ci-robot
added
the
area/enhancements
|
thanks Tim. Here's another one where the CI makes too many assumptions about the various fields being set correctly at the correct times: We had intended to have |
|
If we can define the state-machine, we can code it up as CI. "Error: can't transition directly from state FOO to state BAR". |
|
Copying my comment from the slack channel: Which means that the state machine I'm proposing is (well state-machine seems like a too big word for that, as transitions can go only between adjacent states): In the ideal world how I would see that is:
I admit that adds more burden on the approvers, but given that code-approvers are not necessary the same people are KEP approvers, in the current maturity state of the project I think it would actually be worth it. |
|
Q: this is a speculative issue? Because when I was on the release team, the team did go through the KEPs post code freeze to ensure all PRs intended to merge did merge and if not asked the authors to update the KEPs. While I think there is more granular control we could have on the KEPs, I worry that the reality is that forcing people to update KEPs multiple times within a release post freeze would create a new set of missed updates for authors who previously had no problems creating more issues with up to date KEPs than currently exist. Thinking of something that is lower friction but provides the verification that @thockin rightly wants about the state: Could we ask sigs to somehow verify the state of the KEPs post code-freeze? I'd be more inclined to do this via the release team for 1 release, then see how it works out, get feedback and then memorialize it in the actual KEP template. Further, I think a good point is made, that until the release is released, all the KEP statuses are tentative. I think that is something that we should/could more clearly communicate to outside observers, even outside of the KEP itself - perhaps via docs in the enhancements repo and within the KEP website that is being worked on something like: "all KEPs targeted at the current in-progress release: $RELEASENUMBER are only tentative. please wait until the release is cut on $DATE for the final list and status of KEPs in this release" or some such thing... |
|
As a final note "implemented" is generally used for KEPs that are completely finished post-GA. I think the goal should be that at the end point of the release only the verifiably "finished" KEPs (for their stage) have the release and graduation in their kepy.yaml. IMO we should be removing/updating inaccurate KEPs as opposed to adding a hurdle for accurate KEPs. I'd like to give this a bit more thought, but thanks for raising this |
kikisdeliveryservice
added
the
sig/architecture
This isn't a speculative question - this is a real thing that happened.
|
|
FWIW, the logic itself is pretty easy to change, the tangly bits are in the data, since it's been mostly hand edited YAML that has historically not been validated against much. So for example, if we decide to change We could use |
|
FWIW, the following KEPs lack a
Less toilsome logic we could try instead of "latest-milestone < 1.21":
|
|
#2672 opted to mark everything as implementable and give a dummy "0.0" milestone, we could also add that milestone to everything currently marked as implemented... |
|
I've opened #3007 to add missing metadata and enable the PRR check for implemented KEPs |
|
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
|
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
k8s-ci-robot
added
lifecycle/rotten
|
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
|
@k8s-triage-robot: Closing this issue. In response to this:
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. |
thockin
removed
the
lifecycle/rotten
From slack (summarized):
Is the KEP freeze "you must have all KEP changes merged" or "You must have all intended-to-change KEPs in the sheet"?
For example: I have some KEPs which we WANT to move from Alpha->Beta or Beta->GA, but the code to do those things is not done yet and MIGHT slip. I don't want to change KEP
stagetext until we know whether it is in or not, and that won't be until well after the enhancement freeze.That's not an exception - that's the norm, I think.
I think the only sane interpretation is that the KEP deadline indicates which KEPs are being tracked, but every KEP should be considered "at risk" until stage changes, and when stage changes, that should be authoritative. What I DON'T want is to have to remember to revert changes to a KEP if the code misses the release. That will fail and leave ambiguous results.
Do we need a 2-phase commit - a distinction between target and actual?
We need clarity on the enhancement freeze - what EXACTLY is the deadline for? What sorts of KEP changes are allowed after the enhancement freeze?
Rey said "Enhancements Freeze indicates which KEPs are being tracked ... What the release team looks for in Enhancements Freeze is for the KEP to be marked as "implementable", has the correct stage for the release, ... and an approved PRR"
This says to me that if I want to move to GA in 1.23, I update the KEP to say
GAfor stage. If the code doesn't make it, we have a KEP that is ambiguous (or flat out lying). Expecting people to come back and revert thestageis unrealistic.IMO - stage should be a trailing indicator. Updating stage should be on the success path, not on the failure path.
Some SIGs/reviewers are resetting the status to implemented/implementable for each stage. I don't think that was the intention.
Between
stage,milestone, andstatusthere's overlap and ambiguity. For example, let's look at a new KEP.It starts as:
We iterate on that and it ultimately gets approved:
Development work happens and we release v1.X. Given the above fields, I can assume that this KEP is alpha in v1.X. But if, for some reason, the code missed the boat, someone has to go back and edit the KEP to change
alpha,beta, andga. That is prone to failure, and if it is forgotten, then people might take the wrong result.I think we should instead do soemthing like:
which gets approved to:
When we release v1.X, we can update this to:
This means that someone has to touch the KEP - the same as before, but the failure mode is better. People won't accidentally assume it is ready to use. It would stay in this state until all the code for beta is merged, at which point it becomes:
Obviously, we could model this other ways. E.g. we could have a per-stage status:
The text was updated successfully, but these errors were encountered: