…d builds of the Operator on OCP [RHDHBUGS-2489]
We used to use different methods depending on the type of OCP cluster:
- regular OCP cluster: leveraging
ImageContentSourcePolicy/ImageDigestMirrorSet to let OCP transparently mirror
image pulls from internal registries to quay.io.
- OCP cluster with hosted control plane: unpacking the operator bundles
and manually replacing the internal image refs, because the ICSP/IDMS
approach would not work there
The regular OCP cluster approach works for images that are pulled by
the underlying kubelet, but won't work for image pulls that are done
inside a container (as is the case now with the RHDH
install-dynamic-plugins init container that needs to pull the plugin
catalog index image).
So this simplifies the logic by always using the same method for
installing CI builds of the Operator on OCP.
Description
We used to use different methods depending on the type of OCP cluster:
ImageContentSourcePolicy/ImageDigestMirrorSet to let OCP transparently mirror
image pulls from internal registries to quay.io.
and manually replacing the internal image refs, because the ICSP/IDMS
approach would not work there
The regular OCP cluster approach works for images that are pulled by
the underlying kubelet, but won't work for image pulls that are done
inside a container (as is the case now with the RHDH
install-dynamic-plugins init container that needs to pull the plugin
catalog index image).
So this simplifies the logic by always using the same method for
installing CI builds of the Operator on OCP.
Which issue(s) does this PR fix or relate to
PR acceptance criteria
How to test changes / Special notes to the reviewer
On a regular OCP cluster, install the
nextdownstream build of the Operator:Then create a Backstage CR. Without the changes here, the RHDH init container would fail to start because it would be trying to pull the catalog index image from registry.redhat.io
With the changes here, it should start properly, and the RHDH instance should be accessible.