After some time, daemon sets are being re-deployed for no apparent reason

[ibm]

After some time, daemon sets are being re-deployed for no apparent reason

[whowutwut]

Thanks for cleaning this up, i don't think i have seen it recently.

[mew2057]

So this is basically the fault of a monotonically increasing counter, which doesn't vet that changes actually happened to the secret. I originally implemented it in this way to reduce amount we actually touch the secrets and it was a lazy way to prevent exposures.

The negative is we're over restarting.

My solution to this is two fold:

1. Implement a salted sha512 checksum to track secret changes in the daemonset.

• This change would be in the ansible role and update the templates.

2. Add additional logging to the controller so we can see the name, namespace and label of the secret. This way we can better check how the operator is called.

---

After this is implemented, and cleared I recommend moving this issue to the 1.0.1 milestone so we can do a further refinement after we run tests.

[mew2057]

To point number two the new log for the operator container in the operator will look like this:

{
	"level": "info",
	"ts": 1574362995.7482946,
	"logger": "controller_csiscaleoperator",
	"msg": "In mapping function, mapping to 0 items; Secret: secret1:ibm-spectrum-scale-csi-driver"
}

This says how many operators we're mapping to: mapping to 0 operators. Additionally, it outlines the secret name and namespace. Since this is an investigative fix the namespace is included to track originating namespace.

[mew2057]

Moving to 1.0.1 for further work.

[mew2057]

I have a hunch this is memory related based on the work done in Issue IBM/ibm-spectrum-scale-csi-operator#46.

[mew2057]

This is super stale at this point, @whowutwut have you seen this recently?

[mew2057]

I think this one is cleared, it had something to do with the secret code and it should have been fixed by the secret code fix.