-
Notifications
You must be signed in to change notification settings - Fork 36
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
False positive for API deprecation 1.25 for field last-applied-configuration #36
Comments
I think this comes up time and again because probably when clusters are upgraded, the objects resources are rewritten, not reapplied. So the last-applied-configuration does not reflect the current object metadata - as such it might be a good idea to at least have a flag to ignore that and just grab the actual current manifest. |
Many of the resources are updated manifest (argo syncs it) and show up like this in my cluster
As you can see the But the report returns
Why can't we check for the actual apiVersion in the cluster - |
By default kubernetes returns the manifest in latest version. The actual version which was applied via kubectl apply is available inside |
Thanks for the comment @pghildiyal Also, if addition of a switch is a possibility to scan actual ApiVersion instead of |
I pulled the latest release version of silver-surfer as of creation of this issue, installed and ran according to the documentation called out in the README, and witnessed that the report being generated called out one of our daemonset resources on some clusters are using a deprecated version:
This same issue was happening in the same environment for k8s 1.24 on a different resource referenced here
I have looked in the namespace for the node-exporter in the cluster and inspected its entire -o yaml output there is no single copy of v1beta2 in it. We are unsure of where silver surfer is finding the API it is flagging.
The text was updated successfully, but these errors were encountered: