kubevirt / community

Community content
https://kubevirt.io
50 stars 105 forks source link

design-proposal: Feature lifecycle #251

Closed EdDev closed 6 months ago

EdDev commented 11 months ago

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

The feature lifecycle can be summarized with the following flowchart:

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
    END
kubevirt-bot commented 11 months ago

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 commented 11 months ago

/sig api

kubevirt-bot commented 11 months ago

@EdDev: The label(s) sig/api cannot be applied, because the repository doesn't have them.

In response to [this](https://github.com/kubevirt/community/pull/251#issuecomment-1826836226): >/sig api Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
fabiand commented 10 months ago

@EdDev gentle ping

EdDev commented 10 months ago

@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 commented 10 months ago

change: Answered comments.

EdDev commented 10 months ago

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

EdDev commented 10 months ago

change: Answered review comments.

fabiand commented 9 months ago

/hold

Just holding this to allow me to review this by tomorrow

EdDev commented 8 months ago

change: Answered review comments (not including the one from today)

EdDev commented 8 months ago

change: Added an example to a stable CRD version.

rthallisey commented 8 months ago

/assign @alaypatel07

EdDev commented 7 months ago

change: Answered review comments.

EdDev commented 7 months ago

change: Answered review comments.

iholder101 commented 7 months ago

Let me summarize (just so I'd have all of this in a single place).

Comment still needs to be addressed:

Future tasks / things to remember:


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.

fabiand commented 7 months ago

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

fabiand commented 6 months ago

@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 commented 6 months ago

@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
fabiand commented 6 months ago

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
fabiand commented 6 months ago

Approvers, where do we stand?

/lgtm

vladikr commented 6 months ago

Looks like no one else is objecting besides me, so let's proceed with this. /approve

kubevirt-bot commented 6 months ago

[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

Needs approval from an approver in each of these files: - ~~[OWNERS](https://github.com/kubevirt/community/blob/main/OWNERS)~~ [vladikr] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment
vladikr commented 6 months ago

Approvers, where do we stand?

/lgtm

Aren't you an approver @fabiand ?

fabiand commented 6 months ago

I am. But I was looking for a consensus and thus seeked for somebody else to approve

EdDev commented 6 months ago

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

fabiand commented 6 months ago

I was only looking for another approver to chime in. Vladik did so, thus:

/unhold

fabiand commented 6 months ago

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

  1. High level slides to describe the key elements of this proposal
  2. Email to kubevirt dev with a a summary and pointer to slides
  3. Submission to KubeVirt Summit !

IOW we should make sure that people start to learn about this. Specifically: FG are maturity switches, not configuration. etc