Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Skip already removed APIs #525

Open
phandox opened this issue Aug 31, 2023 · 2 comments
Open

Skip already removed APIs #525

phandox opened this issue Aug 31, 2023 · 2 comments
Assignees
Labels
feature New feature or request not-stale

Comments

@phandox
Copy link

phandox commented Aug 31, 2023

Hi,

I am trying to find a way for kubent to skip checking already removed APIs (for example - PodSecurityPolicy on 1.25+ K8S clusters). From the the debug output, I see that it's trying to fetch the APIs, even when the cluster is already on 1.26.

11:01AM DBG Retrieving: podsecuritypolicies.v1beta1.policy
11:01AM DBG Failed to retrieve: policy/v1beta1, Resource=podsecuritypolicies: the server could not find the requested resource

The reason for this, is that I use GKE and Recommender API will detect clients using deprecated APIs. It will then stop auto-upgrading clusters until no calls to removed or deprecated APIs are made for at least 30 days. Having a flag available, which would turn off calling these already removed API would be great help for me.

If you think it would be useful, I can try to make a PR if we work out some specification how it could work.

Thanks!

@stepanstipl stepanstipl added feature New feature or request not-stale labels Sep 5, 2023
@stepanstipl
Copy link
Contributor

stepanstipl commented Sep 5, 2023

This is a potentially interesting feature, currently not supported.

The implementation should not be too difficult - we would have to introduce new piece of info that we currently don't have, about all the resource/versions and when they stopped being supported. However, it's another bit that's fairly expensive to maintain. Or implement some discovery phase of supported GVKs and only query those, probably better, but more work initially.

In anycase, I see why this would make sense and we will consider implementing it in the future. Thanks for raising this 👍

@madAndroid
Copy link

Similar to this use case, it would be useful to be able to exclude rulesets from the different ones being checked .. we're on 1.24.x, looking to upgrade to 1.25.x, and we're getting failures for 1.22 resources - presumably for legacy manifests still in place on in etcd, even though the resources have been upgraded to newer versions already.
Being able to exclude rulesets would allow us to surface only requirements for specific upgrades

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request not-stale
Projects
None yet
Development

No branches or pull requests

4 participants