CORE-340: Add openshift.ubi9ImageTags helm value

[damemi]

Description

This allows users to install with openshift.enabled=true using non-ubi9 images.

The expected use case is an OpenShift user who has mirrored their own images, but still needs the additional OpenShift settings (RBAC, selinux permissions, etc)

Setting openshift.ubi9ImageTags=false will not append the -ubi9 suffix onto pulled tags. This will only work if the user is not pulling from the Red Hat certified registry (which openshift.enabled=true uses by default), because we only push UBI9 images there.

So, the intended use is to combine this with imagePrefx=docker.io/.....

Example:

---

Install on OpenShift, using non-UBI images from my own registry:

./odigos install --set openshift.enabled=true --set imagePrefix=docker.io/mikeodigos --set openshift.ubi9ImageTags=false

Image format: docker.io/mikeodigos/odigos-odiglet:v1.x

---

Install on OpenShift, using UBI images from my own registry:

./odigos install --set openshift.enabled=true --set imagePrefix=docker.io/mikeodigos

Image format: docker.io/mikeodigos/odigos-odiglet-ubi9:v1.x (this is valid for OpenShift users who are mirroring certified images to their cluster

---

Install on OpenShift, using UBI images from Red Hat:

./odigos install --set openshift.enabled=true

Image format: registry.connect.redhat.com/odigos/odigos-collector-ubi9:v0.0.0

---

INVALID: Install on OpenShift, using non-UBI images from Red Hat (will not work):

./odigos install --set openshift.enabled=true --set openshift.ubi9ImageTags=false

Image format: registry.connect.redhat.com/odigos/odigos-collector:v0.0.0 (does not exist, missing imagePrefix or should not set ubi9ImageTags=false)

How Has This Been Tested?

• Added Unit Tests
• Updated e2e Tests
• Manual Testing
• Manual Load Test

Kubernetes Checklist

• Changes how Odigos interacts with Kubernetes
• Introduces additional calls to the API Server (potential performance impact)
• New Query/feature supported in all the k8s versions supported by Odigos
• Modifies Odigos manifests (addressed in both CLI and Helm)
• Changes RBAC permissions

User Facing Changes

• Users need to take action before upgrading
• Automatic migration will modify existing objects (backward compatible)
• Changes UI, CLI, or K8s Manifests aspects in a way that users need to be aware of
• Documentation updated accordingly

[damemi]

Also fixing a "broken link" flake in the otlphttp destination

[BenElferink]

This doesn't look right to me, OpsVerse logs was disabled due to the deprecation of lokiexporter from contrib

[damemi]

I was also confused by the docs changes. This came out of just running the sync-dest-docs script, so maybe there is an issue locally for me on that

[damemi]

@BenElferink ah the opsverse logs change was reverted https://github.com/odigos-io/odigos/blame/e9f645e3d40c695ae6c108b10f495be25867961f/destinations/data/opsverse.yaml#L15 in #3734

[RonFed]

I'm not sure if there are more places that needs this logic change in the code but one place that comes to mind is: odigos-agents init container we add in the webhhok when the mount method is init-container.

[damemi]

good catch, I think that does need a similar update in code

otherwise, I think all images come from install at this point right?

[damemi]

we actually don't have a RH certified odigos-agents image and the initContainer image helper never uses the -ubi9 suffix