Complex custom_pod_annotations get malformed

Hello,

lately we wanted to add a more complex custom_pod_annotation via the operator configmap. This turns out to be harder than expected. We tried to place an annotation which should look in the output like this: my.custom.annotation/run: "item1,item2,item3".

I tried it with several formats and escapes like this, but the output was malformed and therefore useless.

my.custom.annotation/run: "item1,item2,item3" => yaml validation failed
"my.custom.annotation/run: "item1,item2,item3"" => yaml validation failed
"my.custom.annotation/run: \"item1,item2,item3\"" => will get formated as 'my.custom.annotation/run: "item1,item2,item3"'; resulting annotation: my.custom.annotation/run: ' "item1,item2,item3"'
"my.custom.annotation/run: \"item1\\,item2\\,item3\"" => will get formated as 'my.custom.annotation/run: "item1\,item2\,item3"'; resulting annotation: my.custom.annotation/run: ' "item1\,item2\,item3"'

Maybe you can give me a hint where my mistake lies or if this is even doable?

Please, answer some short questions which should help us to understand your problem / question better?

• Which image of the operator are you using? e.g. registry.opensource.zalan.do/acid/postgres-operator:v1.10.0
  1.10.0
• Where do you run it - cloud or metal? Kubernetes or OpenShift? [AWS K8s | GCP ... | Bare Metal K8s]
  K8s
• Are you running Postgres Operator in production? [yes | no]
  yes
• Type of issue? [Bug report, question, feature request, etc.]
  question

Start by tracing how custom_pod_annotations from the operator ConfigMap are parsed and formatted, then compare the generated annotation with the requested value. Done means a value such as my.custom.annotation/run produces the intended Kubernetes annotation without malformed quoting or escaping.