VolumeSnaphosts are moving to v1 about kube-no-trouble HOT 3 CLOSED

Hello,

Maybe a little refactor to show in addition of removed API the list of currently deprecated API but without removal announce ?

On rules folder something like that ? :

rules/
  1-16-deprecated.rego
  1-16-removed.rego
  1-20-deprecated.rego
  1-21-deprecated.rego
  1-22-deprecated.rego
  1-22-removed.rego
 

Two file per K8s release seems to be easier to maintain rather than 1 global file with deprecation list.

and for console output

__________________________________________________________________________________________
>>> Deprecated APIs annoucement in 1.20 <<<
------------------------------------------------------------------------------------------
KIND          NAMESPACE     NAME                          API_VERSION                     REPLACE_WITH (SINCE)
VolumeSnapshot <undefined>   test-volume   snapshot.storage.k8s.io/v1beta1   snapshot.storage.k8s.io/v1 (1.20+)
__________________________________________________________________________________________
>>> Deprecated APIs removed in 1.22 <<<
------------------------------------------------------------------------------------------
KIND          NAMESPACE     NAME                          API_VERSION                     REPLACE_WITH (SINCE)
TokenReview   <undefined>   test-deprecated-TokenReview   authentication.k8s.io/v1beta1   authentication.k8s.io/v1 (1.19+)

from kube-no-trouble.

Thanks, @dja-fr for the idea, I think it would make sense to have a separate group for announced deprecated APIs, when it's not clear in which version these will be removed.

I'm thinking about two options:

a) As you described, have additional set for each K8s version, then how would the progression over time look like:

• i) API appears in the announced group (like VolumeSnapshot in 1.20)
• ii) Once it's clear when removed, API is moved to corresponding deprecated (like VolumeSnapshot to 1.25 - just an example), I guess we don't want to have rules twice ;)
• iii) the "1.20 - announced" group will eventually disappear

b) Have a generic group for deprecated APIs, without pinning to a specific version

• i) API appears in the generic "deprecated" group
• ii) Once clear when removed, it will move to corresponding deprecated

I'm thinking second might be a bit simpler. But at the same time, we're losing some info, as to when the API was announced as deprecated. Not quite sure if that's important, as we already have "since" information, although it's a bit different.

WDYT?

from kube-no-trouble.

Hi,

We can try b) option.
I'll try to send you a PR. (I'll have some boring meeting this afternoon 😄 )

from kube-no-trouble.