Supporting single vs multi arch images in a stack

[elsony]

The devfile currently contains image information as part of the container component information. This works well if one single image can be run in a different environment or system architecture, e.g. images that can run on p and z may be different from other images. With the current devfile 2.0 spec, the stack provider will need to provide a different stack to allow different images to be run on different system architectures.

Here is a proposed solution for resolving this:

1. Introduce a built-in environment variable to describe the architecture, e.g. PROCESSOR_ARCHITECTURE.
2. The tools (e.g. odo, Che) who are running the devfile will need to set that environment variable and resolve that when running the devfile.
3. On the image field, the user can use the ${PROCESSOR_ARCHITECTURE} reference to control the path of the image. To keep the implementation simple, the image URL can simply have that variable as part of the image location. (The alternative is to have an explicit list of different images based on different architectures.)
   Example of variable usage:

components:
  - name: runtime
    container:
      image: registry.access.redhat.com/ubi8/${PROCESSOR_ARCHITECTURE}/nodejs-12:1-45
      memoryLimit: 1024Mi
      mountSources: true
      sourceMapping: /project
      endpoints:
        - name: http-3000
          targetPort: 3000

4. We also need a way for a stack to declare the list of architectures that a given stack supports via tags. Using a processorArchitecture field in metadata (separated by , for a list of multiple entries)

We can have 2 models:

• opt-out model: by default assume a stack supports all architecture and a stack can specify the list of supported architecture in the metadata in a devfile
• opt-in model: by default assume a stack supports no architecture and a stack must specify the list of supported architecture in the metadata in a devfile before the tools can use it.

[elsony]

Instead of using a global environment variable in the devfile, different architecture support will need to use different devfile file. The different architecture support will be handled by having devfiles with different extensions, e.g. devfile.yaml, devfile_x86.yaml and devfile_s390x and devfile_ppc64le.yaml.

• In the registry common library, the client can pass in the architecture info when fetching the devfile.
• In a registry, index.json will only record the master devfile without the architectural extension.
• A global variable (see Top level attribute definition in a devfile #239) processorArchitecture will be provided for stacks to find the architecture during the execution of the devfile.
• This global variable is a reserved variable and will be referenced using {{processorArchitecture}}

[elsony]

Blocked by #239 for providing global attribute support

[maysunfaisal]

I've put up a draft design on the two ways in the document https://docs.google.com/document/d/1MTgxy2EAFYqvN7Twtbr_iWlG9xsghOyI89RRILxvsqY/edit#heading=h.esvxv0e8cpjx

[elsony]

We'll take a simple approach that we'll no longer provide native support for allowing multiple versions of devfiles with different architecture in a given stack. We'll:

1. introduce an architecture metadata field that the devfile author can provide the list of the supported architectures of a given devfile
2. If a given stack needs to provide devfiles with different contents, e.g. different commands, in order to provide multi-arch support, the stack owner will need to provide two different stack/devfile to support that. (We currently see this case to be fairly rare so we'd like to keep the implementation simple.)
3. As part of the registry build, we'll take a look at the image to see if it is multi-arch or not and automatically add the architecture information. The registry build should provide a warning if the architecture is not specified in the devfile in a given stack. (more on this expanded in comment Supporting single vs multi arch images in a stack #244 (comment))
4. The best practice for onboarding on the community registry is to list all supported architectures on the devfile metadata

In the future, if it turns out there are more use case that needs to provide different architecture support, we'll reconsider to provide support for case #1 in https://docs.google.com/document/d/1MTgxy2EAFYqvN7Twtbr_iWlG9xsghOyI89RRILxvsqY/edit#heading=h.esvxv0e8cpjx.

[maysunfaisal]

Issue Update:

1. A devfile without architecture info is assumed to support all the architectures
2. If a devfile has mentioned architecture a,b,c whereas the container image(s) supports a,b,c & d or lack thereof; we take the devfile architecture info as the source of truth and say that stack/sample supports a,b,c
3. If a devfile has no architecture mentioned,
   • a non-blocking PR workflow is to alert the PR author
   • registry build is to alert that a specific devfile has no architecture information