$ 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)?
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
What version of eunomia are you using? v0.1.6
kubectl exec $EUNOMIA_POD curl localhost:8383/metrics
eunomia version:
Does this issue reproduce with the latest release? Yes
What operating system and processor architecture are you using (
kubectl version
)?kubectl version
OutputWhat 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