[GEP-32] Version Classification Lifecycles

[vknabel]

How to categorize this PR?

/area documentation
/kind discussion

What this PR does / why we need it:
Introduces the GEP-32 to schedule the lifecycle of version classifications. It aims to improve on the currently implemented expirationDate approach.
A reference implementation can be found at metal-stack#9

Which issue(s) this PR fixes:

Special notes for your reviewer:
Implemented as part of the Gardener Hackathon 2024 Q4.

The missing GEP numbers were "reserved" during the hackathon and skipped to avoid conflicts. Corresponding PRs will be opened by other contributors.

FYI to the authors @crigertg @Gerrit91 @LucaBernstein

[gardener-prow]

Hi @vknabel. Thanks for your PR.

I'm waiting for a gardener member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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-sigs/prow repository.

[rfranzke]

/cc @vlerenc @dguendisch

[dguendisch]

The approach sounds good!

• will it be supported to overwrite the lifecycles (by administrators) any time? (e.g. to reflect that a version was once planned to be supported on some date, but during preview was found to be somewhat broken and we'd like to transition such a version rather from preview to deprecated and expired (omitting supported) with earlier startTimes than initially planned)
• I understood that the moment we'd switch to the new lifecycles, we'd have to omit the old/now-deprecated fields, hence potential consumers of the cloudprofile resource would have to "hard-switch" to the new spec once the cloudprofiles on a certain gardener installation/landscape changed to the new format, correct?

[vlerenc]

I like the new proposal a lot - it makes life so much easier and allows to properly define the lifecycle in advance, which makes a lot of sense in combination with the prime entity we manage with this: Kubernetes - with any new Kubernetes version, everything is already communicated, like for how long functional and security patches are provided.

❤️

[Gerrit91]

will it be supported to overwrite the lifecycles (by administrators) any time?

In general yes, but there are few restrictions:

• We planned to prevent changing a start time that would cause a version to move into unavailable stage. Once an version has become available it stays available.
• For NamespacedCloudProfiles there are more complex rules, which @vknabel or @LucaBernstein can explain better.

I understood that the moment we'd switch to the new lifecycles, we'd have to omit the old/now-deprecated fields, hence potential consumers of the cloudprofile resource would have to "hard-switch" to the new spec once the cloudprofiles on a certain gardener installation/landscape changed to the new format, correct?

Both variants are supported as long as desired. At one point in time it should be switched, e.g. in a v1 version of the CloudProfile. For this it would be possible to make a conversion from v1beta1 to v1 if this answers the question?

[dguendisch]

Both variants are supported as long as desired. At one point in time it should be switched, e.g. in a v1 version of the CloudProfile. For this it would be possible to make a conversion from v1beta1 to v1 if this answers the question?

With a new version and a conversion between them would mean that our users would have some migration window and can do the switch whenever they are ready. If that new cloudprofile version is already foreseen, maybe it should be added to the GEP.

[robinschneider]

Thanks for picking up my idea and the work you spend into creating the first implementation.
Really looking forward to have scheduled classifications.

[vknabel]

The latest version of the proposal includes a new section regarding NamespacedCloudProfiles and the version lifecycle. Here we explain how we handle edge-cases during overrides and what an administrator needs to respect during updating a lifecycle. Hope this answers some questions. 😊

[rfranzke]

@vlerenc @dguendisch Can you please have another look so that we can proceed with the GEP? :)

[vlerenc]

@rfranzke I generally liked the idea a lot to switch from manual to a spec describing what shall (automatically) happen to that/a version over time and only had a minor English language comment that got fixed, so:
/lgtm

[gardener-prow]

LGTM label has been added.

Git tree hash: 0d28f7f5be47a010828c3236fcfbc9946157e9b5

[vlerenc]

Looks good to me. Love the proposal.

[dguendisch]

all good from from my side as well
/lgtm

[rfranzke]

Nice, thank you everybody.

Any other feedback? Otherwise, I would propose to merge this in the course of this week so that the folks can focus on the implementation part.

cc @timuthy @LucaBernstein @timebertt

[timebertt]

Kudos to all proposal authors! This is a very well-written GEP. I'm looking forward to the feature ❤️

I don't have any other feedback apart from renaming the status field (#10982 (comment)).

[timuthy]

Nice proposal! No further feedback from my side.
/lgtm

[rfranzke]

/lgtm
/approve

[gardener-prow]

LGTM label has been added.

Git tree hash: b8be021034a50daed6913b1a3994da2e7eaee13f

[gardener-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rfranzke, vlerenc

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 [rfranzke]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rfranzke]

/ok-to-test