Clarify on how to use image name in image component and how tools can consume it

[elsony]

Which area this feature is related to?

/area documentation

Which area is this documentation change is related to?

/area api

Issue details

What mistake did you find / what is missing in the documentation?
The existing imageName field in the image component only has a brief field description. Based on the discussion on the community call on 11/14 (see the recording https://drive.google.com/file/d/1XLTdizST_LeoKpF7xw4Q9k__6LoXKCmo/view?usp=sharing for details), we need to clarify how the imageName field is set and handled by the tools.

Summary of the change:

1. The user can specify the imageName with either a full URL or a relative location of the image within an image registry to store the built image.
2. If a relative location is being used, the tools will have their own way to find out the image registry location (e.g. detection or user input). After the image component is built, it will automatically replace the correct image location in memory so that it can be used by an image container or the kubernetes component for deploying the image.
3. If a full URL is used, the tools will not replace it with the automatically generated URL and will use the full URL to store the built image.

[kadel]

• If a relative location is being used, the tools will have their own way to find out the image registry location (e.g. detection or user input). After the image component is built, it will automatically replace the correct image location in memory so that it can be used by an image container or the kubernetes component for deploying the image.

Shouldn't tools also allow overriding the image name?
Let's say that I have two applications, both using java-springboot stack. This stack defines image component with imageName: java-springboot-image:latest.
Let's say that we have a setting on the tooling side that allows the user to set the registry that should be used. My two different applications will be pushing to the same image. This is definitely not what we want.

[l0rd]

Considering the imageName as a full registry image has collision and permissions problems. We should avoid that.

We should rather consider it an image selector as Tilt does:

my-image is an image selector. Tilt will scan all your workload manifests for images, and match any object that contains the image name my-image (regardless of tag).

So the proposal is to

1. Add a new image component property called imageNameSelector which description is:

An kubernetes and container component image selector. Tools will scan all container and 
kubernetes components for images, and match any object that matches it 
(regardless of the registry and tag).

2. To deprecate the current imageName and replace it in every documentation sample but continue supporting it for backward compatibility as an alias of imageNameSelector.

3. Implement the new behavior in the Devfile library and DWO

---

example

components:
  - name: devtools-image
    image:
      imageNameSelector: devtools                    # <=== image selector
      autoBuild: true
      dockerfile:
        uri: Dockerfile
  - name: devtools-container1
    container:
      image: devtools                                # <=== matches selector ✅
      memoryLimit: 512Mi
      command: ['sleep', 'infinity']
  - name: devtools-container2
    container:
      image: quay.io/devfile/devtools:ubi8-latest    # <=== matches selector ✅
      memoryLimit: 512Mi
      command: ['sleep', 'infinity']
  - name: devtools-container3
    container:
      image: quay.io/devfile/devtools2:ubi8-latest    # <=== doesn't match selector ❌
      memoryLimit: 512Mi
      command: ['sleep', 'infinity']

Tools implementing the devfile spec will:

• Build the Dockerfile, tag and push the resulting image to a user-defined registry (e.g. <local-registry>/<user-org>/<devfile-name>-<image-name>:<build-#>).
• Replace container component images that match the imageNameSelector with the image that has just been built
• Replace kubernetes component containers with images that match the imageNameSelector with the image that has just been built.
• Leave the non matching container and kubernetes components as they are

[rm3l]

I've created a PR in the Devfile library to handle imageName as a selector: devfile/library#172.
@l0rd @elsony @kadel Please take a look and let me know your thoughts.

There is also a draft PR in odo related to that. It leverages the changes in devfile/library#172 and can be used already to test this via odo: redhat-developer/odo#6768