-
Bug
-
Resolution: Done
-
Normal
-
Logging 6.0.0
-
False
-
-
False
-
NEW
-
NEW
-
Release Note Not Required
-
-
Description of problem:
When referencing a ConfigMap or Secret using the new API its name is used to construct a Volume and VolumeMount definition in the resulting DaemonSet. Because the volume name can not contain dots, this can cause errors if the name of the referenced ConfigMap or Secret contains a dot.
Example configuration:
tls:
ca:
key: service-ca.crt
configMap:
name: openshift-service-ca.crt
Error in CLO log:
{"_ts":"2024-07-03T13:26:44.50750009Z","_level":"0","_component":"cluster-logging-operator","_message":"Reconciler error","ClusterLogForwarder":{"name":"my-collector","namespace":"openshift-logging"},"_error":{"msg":"DaemonSet.apps \"my-collector\" is invalid: [spec.template.spec.volumes[11].name: Invalid value: \"config-openshift-service-ca.crt\": must not contain dots, spec.template.spec.containers[0].volumeMounts[9].name: Not found: \"config-openshift-service-ca.crt\"]"},"controller":"clusterlogforwarder","controllerGroup":"observability.openshift.io","controllerKind":"ClusterLogForwarder","name":"my-collector","namespace":"openshift-logging","reconcileID":"459b2882-9a56-4e93-b1af-56833b166b78"}
The usage of the dot in the generated mount path should be fine, but the name used for the volume needs to be sanitized. It is probably safe to just remove the dot, in the example this would lead to the volume name being "openshift-service-cacrt".
I think I would also prefix the generated volume names with "config-" and "secret-" respectively, so that it is not easy for someone to cause an issue when the ConfigMap/Secret name matches one of the existing volume names (though this should only result in an error from the Kubernetes API and not a misconfiguration of the collector).
Version-Release number of selected component (if applicable):
"master" (6.0)
How reproducible:
Create a configuration referencing a ConfigMap/Secret with a dot in its name.
Actual results:
CLO is unable to create the DaemonSet, because the volume definition is rejected by the Kubernetes API.
Expected results:
CLO is able to generate a valid configuration, no matter what names are used in the configuration.