Figure out how we want to specify images for upstream/vs. downstream

[jmontleon]

We are likely going to need to replace upstream images with downstream images, so we'll need to decide how we want to do so and implement it. For the most part this can be as simple as specifying them using env vars on the operator deployment. These can then be updated in an automated fashion during the downstream buils.

See for instance on mig-operator:
https://github.com/konveyor/mig-operator/blob/master/deploy/olm-catalog/bundle/manifests/crane-operator.v99.0.0.clusterserviceversion.yaml#L681-L732

In some cases the deployments using the containers aren't directly launched by the operator (rsync-transfer as a for instance). In these cases we have to think about how we want to pass these in.

I believe crane-runner is also hard coded in a bunch of cluster tasks so we'll have to fix that as well.

[github-actions]

This issue is currently awaiting triage.
If contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.

[rayfordj]

If we're going to be following a similar pattern to previous RHMT products, please consider using RELATED_IMAGE_ prefix from the onset. It will allow us to leverage OSBS's automation and we may then abandon managing image digest collection & injection (manually, via scripts) into downstream CSV for relatedImages.

Reference(s):

• Allow use of RELATED_IMAGE prefixes on FQIN role vars kubev2v/forklift-operator#209
• https://osbs.readthedocs.io/en/latest/users.html#pinning-pullspecs-for-related-images
• https://osbs.readthedocs.io/en/latest/users.html#pullspec-locations

It's not significant for downstream short of letting OSBS due automatically for relatedImages: what we're doing manually (scripted) today. I imagine any reduction in code/script maintenance effort may be a benefit. 🤷‍♂️

[jmontleon]

Thanks for the heads up @rayfordj

We should update to follow this pattern since it will save a lot of pain down the line. cc @djzager @JaydipGabani

[eriknelson]

/triage accepted
/priority normal

[eriknelson]

/kind feature

[github-actions]

This issue synced with: https://issues.redhat.com/browse/MTRHO-117