Uploaded image for project: 'Red Hat OpenShift Dev Spaces (formerly CodeReady Workspaces) '
  1. Red Hat OpenShift Dev Spaces (formerly CodeReady Workspaces)
  2. CRW-1131

Operator needs to be arch-aware and be able to deploy jdk or j9 images as required

    XMLWordPrintable

Details

    Description

      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?

      Attachments

        Issue Links

          Activity

            People

              nickboldt Nick Boldt
              nickboldt Nick Boldt
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: