Per today's discussion on the Operator Framework call, there's no good way with the new bundle format to build CSVs for multiple architectures such that for:

• x86_64: openJDK images are used
• s390x: openJ9 images are used
• ppc64le: openJ9 images are used

This is caused by the fact that operator metadata container builds in Brew no longer allow multistage Dockerfiles (new bundle format) as reported in https://projects.engineering.redhat.com/browse/RHELBLD-2219.

So to work around this, we can load multiple versions of the same container into the relatedImages section of the CSV, eg., with variations on the RELATED_IMAGES_ env vars:

- name: RELATED_IMAGE_keycloak
  value: registry.redhat.io/rh-sso-7/sso74-openshift-rhel8:7.4 # [x86_64 only]
- name: RELATED_IMAGE_keycloak_s390x
  value: registry.redhat.io/rh-sso-7/sso74-openj9-openshift-rhel8:7.4 # [s390x only]
- name: RELATED_IMAGE_keycloak_ppc64le
  value: registry.redhat.io/rh-sso-7/sso74-openj9-openshift-rhel8:7.4 # [ppc64le only]

But we need a mechanism inside the operator golang code itself to be able to choose the correct image if defined (and fall back to the non-openj9 variant if not present).

abazko is that something we can do in the next sprint?