[Fortune-Ndlovu]

Every container image the operator can inject into a workload it creates must be listed in the CSV's spec.relatedImages and must be overridable through a matching RELATED_IMAGE_* environment variable.

This is the standard Red Hat operator pattern. It generalizes the existing backstage / postgresql substitution to every operator-chosen image.

Images covered

Image	Required when	Env var
backstage	Always	RELATED_IMAGE_backstage (existing)
postgresql	Local DB enabled	RELATED_IMAGE_postgresql (existing)
lightspeed-core	Always in 2.1+ (Intelligent Assistant is enabledByDefault: true)	RELATED_IMAGE_lightspeed_core
okp	intelligent-assistant-okp add-on (opt-in)	RELATED_IMAGE_okp
sonataflow psql job	orchestrator (opt-in)	reuses RELATED_IMAGE_postgresql
ubi10-minimal	orchestrator (opt-in)	RELATED_IMAGE_ubi_minimal
Tekton git image	orchestrator (opt-in)	RELATED_IMAGE_tekton_git
plugin-installer	OPERATOR_DP_PROCESSING=true (dev preview; GA gate)	RELATED_IMAGE_plugin_installer

Feature: https://redhat.atlassian.net/browse/RHDHPLAN-1887

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

[rhdh-qodo-merge]

PR Summary by Qodo

ADR: Define disconnected image inventories for Operator and Helm

📝 Documentation 🕐 20-40 Minutes

AI Description

• Defines release-specific static container image inventories for disconnected Operator and Helm
 installs.
• Establishes Declare → Discover → Mirror → Resolve using Operator relatedImages and chart values.
• Identifies owning repositories, planned validation, and separate handling for dynamic plugin
 artifacts.

Diagram

graph TD
  A["Operator profiles"] --> B["Bundle relatedImages"] --> C["Mirror tooling"] --> D["Customer registry"] --> E["Running workloads"]
  F["Helm chart values"] --> G["Mirror guidance"] --> D
  F -->|"image overrides"| E

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Document manual image lists

• ➕ Avoids immediate changes to Operator tooling and bundle generation.
• ➖ Lists can drift as flavours and dependencies change.
• ➖ Leaves no auditable inventory for automation.

2. Scan every bundle manifest

• ➕ Could discover images omitted from the CSV as a temporary safeguard.
• ➖ Depends on bundle layout and does not establish one authoritative inventory.

Recommendation: The ADR’s separate, version-bound sources of truth are preferable: relatedImages gives Operator tooling an auditable contract, while Helm can reuse chart values without a duplicate inventory. Keep manifest scanning, if needed, as a transitional check rather than the primary contract.

Files changed (1) +111 / -0

Documentation (1) +111 / -0

009-disconnected-install-container-image-inventory.mdRecord the disconnected static-image inventory decision +111/-0

Record the disconnected static-image inventory decision

• Adds an ADR defining how Operator and Helm installs declare, discover, mirror, and resolve static container images. It identifies implementation repositories and planned CI and documentation work, excludes dynamic plugin artifacts, and records alternatives and trade-offs. This PR documents intent; it does not implement the tooling or inventory changes.

decisions/009-disconnected-install-container-image-inventory.md

[Fortune-Ndlovu]

/agentic_review

[rhdh-qodo-merge]

Code review by qodo was updated up to the latest commit 77baff9

[gazarenkov]

I think mirror configuration should be a first class citizen for RHDH Operator.
The best approach I see for the time being is:

• configure mirrors on operator level (using ConfigMap of known format)
• if configured make operator apply it

It is already applied for dynamic plugins (see https://redhat.atlassian.net/browse/RHIDP-15003) and we can pretty easily extend it for others, such as: plugin related sidecars or pod resources and even for backstage and postgre images as well.

This way our disconnected env related instruction would be as easy as:

• mirror images locally with oc-mirror oe skopeo etc. (we can consider some tool for forming list of images based on catalog, default-config manifests as well)
• create mirror configMap before start operator (or restart it)

This way mirroring will be applied dynamically, on reconciliation with no additional actions.

WDYT?

[Fortune-Ndlovu]

Hey @gazarenkov ,

You're absolutely right, mirror configuration should be a first-class citizen. I've revised the ADR to adopt your ConfigMap-based approach instead of extending spec.relatedImages.

Here's what changed: The operator already does runtime mirror resolution for plugin packages via the plugin-registry-mirror ConfigMap. Users create one ConfigMap with their mirror mappings, and the operator reads it during reconciliation and rewrites the package URLs. This ADR now extends that same mechanism to container images.

The flow works like this: Users create the ConfigMap once with all their registry mappings (plugins + containers). The operator loads it at startup, then during each Backstage reconciliation, it applies those mirror mappings to both plugin OCI packages (already working) and container image references in Deployments/StatefulSets (new). The pods end up with already-resolved registry paths, no IDMS/ITMS needed.

This keeps everything dynamic (ConfigMap changes apply on next reconciliation), works everywhere the operator runs (including Rosa HCP where IDMS/ITMS are blocked), and solves the optional feature problem users only mirror what they actually enable.

cc: @rm3l

[Fortune-Ndlovu]

/agentic_review

[Fortune-Ndlovu]

/agentic_review

[gazarenkov]

I see it as a (obvious :) ) workaround to improve experience with OLM before new operator processing come to GA and we can benefit dynamic mechanism consistent with RHDH as a platform for dynamic plugins.