Specify and use OLM relatedImages in the operator

[l0rd]

Is your enhancement related to a problem?

There is a new convention to specify the images that an operator and the operand will need that provide a better offline support on OCP 4.3: the spec document

Describe the solution you'd like

As mentioned in the proposal we should:

• Add a relatedImages section in the ClusterServiceVersionSpec. Some images should be flagged as required (che-server, keycloak, postres, devfile and plugin registry, che-theia, brokers etc...) others not (plugins sidecars and stacks)
• Update the operator deployment yaml and the operator itself to leverage the olm.relatedImage annotations
• Remove current CR attributes airGapContainerRegistryHostname and airGapContainerRegistryOrganisation

[davidfestal]

Should it still be in the OSIO backlog ?
cc @ibuziuk @nickboldt @tolusha

[davidfestal]

We should still think about the pure Kubernetes, non-OLM case, that should still support Airgap I assume.

[tolusha]

@l0rd
Is it part of the epic ?
#15350

[davidfestal]

@l0rd It seems to me it is.

[l0rd]

This one looks like a pre-requisite for #15350. So yes. I though we had already addressed that.

[nickboldt]

We should still think about the pure Kubernetes, non-OLM case, that should still support Airgap I assume.

Or you could say that if you want airgap the Openshift 4.3+ way, you need openshift. :D

BTW for OCP 4.5, see #16815

[davidfestal]

This one looks like a pre-requisite for #15350. So yes. I though we had already addressed that.

On CRW side for the 2.1.0 release the relatedImages section is added on the CSV at build time. When preparing the brew build, build process gathers all the digests and add them in the relatedImages on the CSV that needs it.
For upstream, it should obviously be managed a bit differently.

Also note that operator framework team is working on supporting tags in the relatedImages and having them replaced automatically by digests. But once again we should check if this mechanism would be CRW-specific, or also supported for community operators.

[AndrienkoAleksandr]

Hello, @l0rd @davidfestal @nickboldt Do we need this feature for nightly CSV?

[nickboldt]

I don't need it for nightly for CRW (we rebuild from source, don't reuse Che bits) but @dmytro-ndp might need it for testing Che CI builds...

[AndrienkoAleksandr]

Hello, @l0rd @davidfestal @nickboldt Do we need this feature for nightly CSV
I don't need it for nightly for CRW (we rebuild from source, don't reuse Che bits) but @dmytro-ndp might need it for testing Che CI builds...

we don't have nightly for OLM unfortunately...

[AndrienkoAleksandr]

Hello, about current state of this issue.
Sorry, but about this the spec document I applied need changes to pr, but then I reverted most of them, because I found this spec is alpha and it was not implemented . So we can't use "olm.relatedImage" annotation and "required" field in the relatedImages( actually field "required" called in the spec "default").

So in the pr eclipse-che/che-operator#274 I included to the release scripts adding section relatedImages for CSV files.