Missing "ownerReferences" in configMap "chi-storage-clickhouse"
using ArgoCD to deploy ClickHouseInstallation result with a configMap named chi-storage-clickhouse that argocd want to delete.
Because clickhouse-operator propagate the label argocd.argoproj.io/instance and there is no ownerReferences
I think there is two solutions to fix that :
- first: don't propagate
argocd.argoproj.io/instance - second: add
ownerReferences
I think this issue could be fixed here:
https://github.com/Altinity/clickhouse-operator/blob/master/pkg/controller/chi/kube/cr.go
Having the same issue. I don't believe this was an issue in version 0.24 of the operator.
Adding ownerReferences appears to be the correct solution since otherwise deleting the ClickHouseInstallation won't delete the ConfigMap and it will end up remaining as an orphan resource.
I confirmed that the bug isn't present on 0.24.0, this version of the operator doesn't appear to create this configmap at all.
However it is present on 0.24.5.
Not sure when the configmap code was added.
I ran into some issues with chi-storage-* ConfigMap recently, and I think they are related to the missing owner reference as well.
I'm using clickhouse-operator 0.24.5. Every time I deploy clickhouse, I see in the operator logs that it's purging chi-storage-* ConfigMap from this part of the code. So far I figured out that the reason the ConfigMap is being deleted is that it is detected as an unknown object. I verified it by changing reconciling.cleanup.unknownObjects.configMap property to Retain, then the operator doesn't delete it. As far as I understand from the code, it is detected as unknown because of the missing owner reference.
Since this ConfigMap is also updated reasonably often, sometimes it runs into a weird race condition. The cleanup process deletes the ConfigMap and starts a poller to check the the delete operation succeeded. If another process updates the ConfigMap shortly after, then the poller waiting for deletion keeps running until the timeout, which prolongs clickhouse deploys unnecessarily.
Planned for fix in 0.25.1