Define behaviour for `CRD` and `ConfigMap` containing the same profile about security-profiles-operator HOT 6 CLOSED

Would be fine having it configurable, while having the CRD be the new default :)

from security-profiles-operator.

@cmurphy @saschagrunert @hasheddan any suggestions on other options or favourite options? I personally would be leaning towards the first one.

from security-profiles-operator.

It might be easier to just use different paths. The path for a profile created as a ConfigMap versus a CRD are already naturally different, since both the name of the ConfigMap and an explicit name for the file are used to construct the path, e.g. /var/lib/seccomp-operator/<namespace>/<configmap name>/<file name>, but there is no equivalent explicit file name for the CRD (unless we want to add it), so it would be more straightforward to write them to something like /var/lib/seccomp-operator/<namespace>/custom-profiles/<resource name>.json. Then there would only be a collision if a ConfigMap happened to use "custom-profiles" as its name. But I can see arguments for option 1 as well.

from security-profiles-operator.

@cmurphy My main concern would be the edge case you already called out, which makes me feel like option 2 may become a footgun as it gives users some room for misinterpretation.

from security-profiles-operator.

After some talk on this subject we come to the conclusion that we were better-off removing ConfigMap support.

This change will make it easier for users to use the operator and remove unnecessary ambiguity.
Closing this issue given that its goal was to define the behaviour, which no longer is needed.

/close

from security-profiles-operator.

@pjbgf: Closing this issue.

from security-profiles-operator.