community
community copied to clipboard
kubevirt
design-proposal: Feature lifecycle
Kubevirt requires a process with a clear policy on how features are introduced, evaluated and finally graduated or dropped.
This proposal defines the steps and policies to follow in order to manage a feature (lifecycle) in Kubevirt.
This work is attempting to formalize various discussions held at different occasions in the last few years. Mostly triggered by the observation that we collect unused features and frag them for long periods with the need to maintain them in the codebase and documentation.
A previous draft version of this content has been started by @iholder101^1. It is a bit different in the format and focus, but it tried to solve the same challenge.
There has also been a fruitful discussion in the new sig-api, on several API stability topics^2, some with strong relation to the topics discussed in this proposal.
We should continue the discussion and evolve the proposal in order to agree on a formal policy. I hope to see the big picture agreed on first, letting the details follow up immediately after (not necessarily in this proposal).
Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all
@EdDev: The label(s) sig/api cannot be applied, because the repository doesn't have them.
In response to this:
/sig api
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.
@EdDev gentle ping
I had to finish other tasks, but now I'm focus on it. Looking to finish going over all the feedback and respond today.
@EdDev gentle ping
I had to finish other tasks, but now I'm focus on it. Looking to finish going over all the feedback and respond today.
Done.
Let me summarize (just so I'd have all of this in a single place).
Comment still needs to be addressed:
- https://github.com/kubevirt/community/pull/251#discussion_r1553113933: I think this one is important for special cases. While I don't think it should block this proposal, I think it would be much better to add a paragraph regarding this.
Future tasks / things to remember:
- https://github.com/kubevirt/community/pull/251#discussion_r1547414308: a need to change DP template to include graduation criteria similar to k8s. I'll gladly take it upon myself to drive this forward.
- https://github.com/kubevirt/community/pull/251#discussion_r1553061588: this comment is super important in my opinion, as we have to remember that this proposal (intentionally) avoids clearly defining a feature.
- [low-prio] https://github.com/kubevirt/community/pull/251#discussion_r1549763595: introduce a mechanism to enable FGs by default?
While I think this proposal is not complete, and just the first phase of this effort, I think it's a great start and overall I'm very much for it. One again, thanks a lot @EdDev for driving this forward after my work on the subject was abandoned while I was drafted. This wouldn't be possible without you, or at least would have been dragged out for much longer. Thank you, great job!!!
/lgtm
EDIT: you're welcome to ping me for approval once you feel there's a broad agreement and everyone had a chance to raise their concerns.
While I think this proposal is not complete, […] it's a great start and overall I'm very much for it. One again, thanks a lot @EdDev
+1
Maybe somewhere we want to note: It does not have to be perfect, but better than before.
@EdDev thanks for taking this journey. Please look at converging the opern conversations, and then it seems like there is much support for this proposal.
I do think that we should look at some things async
- "API" / CLI flags to differentiate between disabled/enabled by default FGs
- Convention for FG comments in code to track when an FG got introduced (i.e. https://github.com/kubevirt/kubevirt/blob/01f3d4c4ec4d4920af7ed3c10d9acbc62fac8c9a/pkg/virt-config/feature-gates.go#L74-L78)
@EdDev is the following flow correct:
flowchart LR
Start --> Design
Design -- Accepted --> Implementation
Design -- Rejected --> END
Implementation --> QAlpha
QAlpha{Requires Alpha?}
QAlpha -- Yes --> Alpha
QAlpha -- No --> QBeta
QBeta{Requires Beta?}
QBeta -- Yes --> Beta
QBeta -- No --> GA
GA --> Maintenance
Maintenance --> QDeprecation
QDeprecation{Should be deprecated?}
QDeprecation -- Yes --> Deprecation --> Removal
Maintenance & Removal --> END
END
@EdDev is the following flow correct:
Nice.
How about something like this:
flowchart LR
Start --> Design
Design -- Accepted --> Implementation
Design -- Rejected --> END
Implementation --> QGA
QGA{Requires evaluation?}
QGA -- Yes --> QAlpha
QGA -- No --> GA
QAlpha{Requires Alpha?}
QAlpha -- Yes --> Alpha
QAlpha -- No --> Beta
Alpha -- Successful --> Beta
Alpha -- Aborted --> Deprecation
Beta -- Successful --> GA
Beta -- Aborted --> Deprecation
GA --> Maintenance
Maintenance -- Exception --> Deprecation
Deprecation --> Removal
Removal --> END
Maintenance --> Maintenance
END
Nice!
Fixed some arrows and added new major api:
flowchart LR
Start --> Design
Design -- Accepted --> Implementation
Design -- Rejected --> END
Implementation --> QGA
QGA{Requires evaluation?}
QGA -- Yes --> QAlpha
Beta -- Successful --> GA
QGA -- No --> GA
QAlpha{Requires Alpha?}
QAlpha -- Yes --> Alpha
Alpha -- Successful --> Beta
QAlpha -- No --> Beta
Alpha -- Aborted --> Deprecation
Beta -- Aborted --> Deprecation
GA --> Maintenance
Maintenance -- Exception --> Deprecation
Deprecation --> Removal
Removal --> END
Maintenance --> Maintenance
Maintenance -- New Major API --> Removal
END
Looks like no one else is objecting besides me, so let's proceed with this. /approve
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: vladikr
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~OWNERS~~ [vladikr]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
I am. But I was looking for a consensus and thus seeked for somebody else to approve
/hold
Just to make sure that all discussion converges.
@fabiand , do you think we have enough agreement to take this in? (we have other members & approvers lgtm it already)
I was only looking for another approver to chime in. Vladik did so, thus:
/unhold
Folks, this is dope! :)
@edDev now that you have became a writer (the doc is so detailed and long) - How do you feel about 3 things
- High level slides to describe the key elements of this proposal
- Email to kubevirt dev with a a summary and pointer to slides
- Submission to KubeVirt Summit !
IOW we should make sure that people start to learn about this. Specifically: FG are maturity switches, not configuration. etc