Pluto mistakes a ControllerRevisions resource for a DaemonSet resource #432
Labels
bug
Something isn't working
good first issue
Good for newcomers
pinned
Prevents stalebot from removing
What happened?
When running
pluto detect-api-resources --target-versions k8s=v1.21.0
on my AWS EKS Kubernetes cluster four resources of typeDaemonSet
with namekube-proxy
were listed as being a removed versionextensions/v1beta1
.Upon looking at the single
kube-proxy
resource there was noextensions/v1beta1
value in thekubectl.kubernetes.io/last-applied-configuration
orapiVersion
fields of this resource.When debugging and stepping through the code I realised that this was actually referring to a
ControllerRevisions
resource and not aDaemonSet
. It seems the code prioritises thekubectl.kubernetes.io/last-applied-configuration
annotation to get thekind
of resource rather than carrying through the original resource kind.What did you expect to happen?
I expected the output to show me the correct resource and where to look, saying the
DaemonSet
resource was the removed kind did not make me think about theControllerRevisions
resource.How can we reproduce this?
This might be something OpenShift / AWS EKS related as the ControllerRevisions resource doesn't seem to be standard Kubernetes.
Creating a
ControllerRevisions
resource and setting the annotationkubectl.kubernetes.io/last-applied-configuration
toshould be able to reproduce this.
Version
v5.12.0
Search
Code of Conduct
Additional context
Happy to submit a PR eventually if keeping the original resources Kind and not using the kind in the change annotations JSON is the way to go.
As a work around I am currently editing the
ControllerRevisions
kubectl.kubernetes.io/last-applied-configuration
to manually remove the bad API versions.The text was updated successfully, but these errors were encountered: