Repository navigation
Clarify on how to use image name in image component and how tools can consume it #985
Description
Activity
- 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 usingjava-springbootstack. This stack definesimagecomponent withimageName: 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.Considering the
imageNameas a full registry image has collision and permissions problems. We should avoid that.We should rather consider it an image selector as
Tiltdoes: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
- Add a new image component property called
imageNameSelectorwhich 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).-
To deprecate the current
imageNameand replace it in every documentation sample but continue supporting it for backward compatibility as an alias ofimageNameSelector. -
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
containercomponent images that match theimageNameSelectorwith the image that has just been built - Replace
kubernetescomponent containers with images that match theimageNameSelectorwith the image that has just been built. - Leave the non matching
containerandkubernetescomponents as they are
- Add a new image component property called
- added a commit that references this issue
on Apr 19, 2023 - added 9 commits that reference this issue
on Apr 24, 2023 I've created a PR in the Devfile library to handle
imageNameas 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
odorelated to that. It leverages the changes in devfile/library#172 and can be used already to test this viaodo: redhat-developer/odo#6768- added 4 commits that reference this issue
on May 10, 2023
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
imageNamefield 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:
imageNamewith either a full URL or a relative location of the image within an image registry to store the built image.