Check if preferred api version exists #82
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Signed-off-by: Ricardo Pchevuzinske Katz ricardo.katz@gmail.com
Fixes #72
This PR adds a new validation into objects:
First it maps all the Kind objects existing in the swagger.json to a ResourceName and a preferred Group/Version (type PreferredResource map[string]ResourceStruct)
Then, when checking all the Deprecated APIs in the K8S cluster, if the GroupVersion that is being verified is different from the Preferred GroupVersion for the same Kind, it tries to list both of them in the cluster. If the length of the objects is the same it's very likely the API server supports both of them so we can disregard those objects as being deprecated.
Otherwise they're deprecated.
A test that can be run is against Kubernetes 1.13 created with KinD (kind create cluster --image kindest/node:v1.13.12@sha256:214476f1514e47fe3f6f54d0f9e24cfb1e4cda449529791286c7161b7f9c08e7), as that version contained a PriorityClass in scheduling.k8s.io/v1beta1, which is deprecated.
Something to note here is that the API Walker have a slight different behavior, as if the object kind is not existent in the swagger.json and we use the PreferredResource method it might mask still some deprecated object but still...as the API Server in those cases prefer what it calls the Preferred, it will still return the extensions/v1beta1/deployments as preferred and everytime consider that a Deleted API.
This might raise some alert for the cluster-admin as "please please please do release upgrades in steps before jumping from 1.13 to 1.18"
@codescalar @yogeek PTAL, if possible run some tests with this branch :) I'm planning to merge in the middle of the week and maybe release a beta version