Operator errors when opamp bridge image is pinned to a specific sha

[jdcrouse]

Component(s)

operator, opamp bridge

What happened?

Description

The operator is attempting to set the entire sha as a label when pinning the bridge to a specific sha, which is too long and leads to an error that prevents the bridge from being created

Steps to Reproduce

Configure an opamp bridge with the image set to a specific git sha from here
example:

image: "ghcr.io/open-telemetry/opentelemetry-operator/operator-opamp-bridge:main@sha256:00738c3a6bca8f143995c9c89fd0c1976784d9785ea394fcdfe580fb18754e1e"

Expected Result

The operator would successfully create an opamp bridge with the desired image version

Actual Result

The opamp bridge gets stuck on container creation and the operator spits out the error below (the sha is being set as a label, but the value is not truncated so it will always be too long)

"error":"ConfigMap \"dev-opamp-bridge-opamp-bridge\" is invalid: metadata.labels: Invalid value: \"00738c3a6bca8f143995c9c89fd0c1976784d9785ea394fcdfe580fb18754e1e\": must be no more than 63 characters"

Kubernetes Version

1.28.3

Operator version

0.92.1

Collector version

0.92.0

Environment information

No response

Log output

"error":"ConfigMap \"dev-opamp-bridge-opamp-bridge\" is invalid: metadata.labels: Invalid value: \"00738c3a6bca8f143995c9c89fd0c1976784d9785ea394fcdfe580fb18754e1e\": must be no more than 63 characters"

Additional context

No response

[jaronoff97]

part of this is related to #2399. It would be great if we could bubble this up to the user when they apply CRDs rather than opaque operator logs. The solution here will involve fixing the SHA, but to me the real issue that we created manifests that were invalid. i.e. the deployment was created but because the configmap wasn't the pod was stuck in containercreating.

[jaronoff97]

Kristina has offered to work on this :) 🎉