derailed
StatefulSet incorrectly determines apiVersion
Describe the bug The StatefulSet sanitizer (and probably others also) determine the apiVersion incorrectly when the StatefulSet is created by an operator.
To Reproduce Steps to reproduce the behavior:
- Install the prometheus-operator.
- Look at the
alertmanager-mainStatefulSet - Run
popeye -l warn -s sts - See error
Expected behavior
The correct apiVersion is found, and violation is only reported when it's not the current one.
Screenshots If applicable, add screenshots to help explain your problem.
Versions (please complete the following information):
- OS: OSX
- Popeye 0.4.3
- K8s 1.14.8
Additional context
The problem is due to the fact that the operator adds the CRD source as kubectl.kubernetes.io/last-applied-configuration annotation. This includes, in the case of the prometheus-operator, its own apiVersion monitoring.coreos.com/v1 for the kind Alertmanager.
In sanitize/sts.go, line 56, the apiVersion is tried to be determined from that annotation, and only in case of errors, the fallback of trying to determine it from the selfLink is used. If this mechanism would be used as the default, the error would not appear.
I don't know what's the background of the approach to get the apiVersion from the annotation, so I cannot estimate if this change would cause problems somewhere else...
@djablonski-moia Thank you for your great report and investigation! Good catch!! I think your assessment is correct as we actually check both the annotation and the self link which sadly has been deprecated ;( So this check is now a dud. In the case the resource is created via CRD we do indeed need a different strategy to check the resource version. I've been struggling with this. I think we can't rely on the crd annotations being present in the general case. I think we need to scan for the preferred etcd resource versions. I'll take a look and see how we can best address this.
@derailed Thanks! If there is anything I can do to support, please let me know...
@djablonski-moia Very kind of you! I do really appreciate your support and interest! I am able to reproduce this. I think I've found a solution for it that's going to require a bit of surgery ;( For now I will change this check and validate the link first as the annotation, as you've point out only applies when the resource is created via the CLI. I'll keep this issue open to make sure we track it in the mean time.
Hi @derailed!
At least in our clusters the latest version does not show this issue anymore, so from my side it would be fine to close this issue 😄
I see a related problem, if not the same one, on Deployments.
In a K8s 1.18 cluster, this is shown:
😱 [POP-403] Deprecated Deployment API group "apps/v1beta1". Use "apps/v1" instead.
However kubectl get deployment <name> -o yaml shows:
apiVersion: apps/v1
kind: Deployment
metadata:
...
Using popeye v0.9.0
