Changes in configmap for freshclam is overwritten when reconciling updater DaemonSet. Bug or feature?

[oekarlsson]

Describe the bug
I found the configmap kubeav-updater and saw that I could use this to add additional signature databases. But the complete configmap are updated and the content is reset when the code for reconciling updater DaemonSet is run every 30 minutes. Since this project is in it's early stages (but works well) it is perhaps not correct to call it a bug. But I do not know if I would call it a feature either.

To Reproduce
Make some changes in the configmap called kubeav-updater. Wait for about 30 minutes or until the controller do "reconciling updater DaemonSet". The configmap data is overwritten.

Expected behavior
I would like that my added signature databases was left intact in the configmap. A simple solution could be to only create the configmap if it does not exist. That would make the configmap a lot more useful.

Operator context
Helm, latest

Kubernetes context
Kubernetes Server version: 1.19

[martin-helmich]

Thanks for the (positive) feedback. Let's just call this a "missing feature". 😉

We haven't thought yet about adding any customization options (besides to what the operator does itself). I agree that just leaving the config map as-is when it already exists might be a viable solution. In theory, we could also move the updater daemonset+configmap out of the operators scope entirely, and have it just be deployed by the Helm chart (which might then add further customization options).

[oekarlsson]

Yes, having a default config, but make it possible to change or at least add to it it in the Helm chart is a of course a better solution in the long run. Even clamd.conf could be a configmap handled in the same way. I should try out Go for the first time and perhaps do some contributions :-) If you could fix this quick now by just not updating the configmap, I can almost promise that I eventually would find time to try to implement it using values from the Helm chart. Any good links on how to set up an environment for development/testing of a Kubernets controller like this?

That's assuming you would like contributions of course...