Based on the discussion in today's Container Factory quarterly planning call, issues related to respinning operator-metadata containers when operands (related images) are going to be addressed in the next quarter.

• https://projects.engineering.redhat.com/browse/CLOUDWF-1294

However, this issue around arbitrary image connections (eg., our registries referencing the digests of other containers) will likely NOT get done as it's been dubbed an Edgey McEdgeFace Case.

• https://projects.engineering.redhat.com/browse/CLOUDWF-1293

Thus, we need to instead do this:

• switch to digest pinning (available in OSBS pipeline today but not yet enabled in CRW 2.2)
  • https://osbs.readthedocs.io/en/latest/users.html#pinning-pullspecs-for-related-images
  • https://docs.engineering.redhat.com/display/CFC/Digest_Pinning
• disable our own generation of RELATED_IMAGES metadata, so that digest pinning happens automatically in Brew
• this will then allow the operator to access the RELATED_IMAGES env vars and can delegate them into other containers

THEN, we need to:

• rewrite the devfile and plugin registries so that they can refer to TOKENS instead of hardcoded container references, and access the above RELATED_IMAGES env vars
  • (THIS IS THE HARD BIT)

This would allow us to:

• remove 2/3rds of the current push-rebuilt-container-to-quay, as we would no longer have to rebuild the registries
• remove 2/3rds of the current update-digests-in-registries-and-metadata job, as we would no longer have to check for new registries (they'd be treated the same as sidecars and theia images) any new image would simply trigger a new operator-metadata build.