KohlsTechnology / eunomia

A GitOps Operator for Kubernetes
Apache License 2.0
148 stars 37 forks source link

Resource Deletion with Eunomia ignoring resources in other namespaces #335

Closed Beardface123 closed 2 years ago

Beardface123 commented 4 years ago

What version of eunomia are you using? v0.1.6

kubectl exec $EUNOMIA_POD curl localhost:8383/metrics

$ kubectl get -n eunomia-operator endpoints/eunomia-operator -o jsonpath='{.subsets[*].addresses[*].targetRef.name}' | xargs -I% kubectl exec -n eunomia-operator % -- curl -sS localhost:8383/metrics | grep eunomia_build_info
# HELP eunomia_build_info A metric with a constant '1' value labeled by version from which eunomia was built, and other useful build information. # TYPE eunomia_build_info gauge eunomia_build_info{branch="HEAD",builddate="20200326-23:01:28",gitsha1="988739ae96d923d1d9913ebeff54dabdae942058",goversion="go1.13.9",operatorsdk="v0.8.1",version="v0.1.6"} 1

eunomia version:

Does this issue reproduce with the latest release? Yes

What operating system and processor architecture are you using (kubectl version)?

kubectl version Output
$ kubectl version

Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.5", GitCommit:"20c265fef0741dd71a66480e35bd69f18351daea", GitTreeState:"clean", BuildDate:"2019-10-15T19:16:51Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"15+", GitVersion:"v1.15.9-gke.24", GitCommit:"39e41a8d6b7221b901a95d3af358dea6994b4a40", GitTreeState:"clean", BuildDate:"2020-02-29T01:24:35Z", GoVersion:"go1.12.12b4", Compiler:"gc", Platform:"linux/amd64"}

What did you do?

I submitted a Eunomia job that builds objects in two namespaces. After these resources were created, I removed them from github, and made Eunomia trigger a reconcile to remove the objects from kubernetes.

What did you expect to see?

I expected to see resources in both namespaces deleted

What did you see instead?

Resources in one of the namespaces weren't tagged for deletion. Logs attached contain a list of the target resources (at the bottom). All resources with a ** were not deleted. pod_output.log

seanmalloy commented 4 years ago

@Beardface123 thanks for the bug report. One more detail that I'll mention is that this bug can be consistently reproduced.