Automount image volumes annotation vs. volumes of type image

[vikas-goel]

Issue Description

Podman 5.1.0 lists that a new feature was added for volumes of type image via #23819. In the same pull request, the automount image volumes annotation (io.podman.annotations.kube.image.automount/$ctrname) is made deprecated.

However, I do not see that #23819 has test cases for the use-cases that the annotation (added via #22410) solves.

`Automounting Volumes`

An image can be automatically mounted into a container if the annotation `io.podman.annotations.kube.image.automount/$ctrname` is given. The following rules apply:

- The image must already exist locally.
- The image must have at least 1 volume directive.
- The path given by the volume directive will be mounted from the image into the container. For example, an image with a volume at `/test/test_dir` will have `/test/test_dir` in the image mounted to `/test/test_dir` in the container.
- Multiple images can be specified. If multiple images have a volume at a specific path, the last image specified trumps.
- The images are always mounted read-only.
- Images to mount are defined in the annotation "io.podman.annotations.kube.image.automount/$ctrname" as a semicolon-separated list. They are mounted into a single container in the pod, not the whole pod. The annotation can be specified for additional containers if additional mounts are required.

Can you confirm that the 5.1.0 feature supports the annotation use-cases? If so, it will be good to add the corresponding test cases to avoid regressions.

Steps to reproduce the issue

Steps to reproduce the issue
1.
2.
3.

Describe the results you received

Describe the results you received

Describe the results you expected

Describe the results you expected

podman info output

If you are unable to run podman info for any reason, please provide the podman version, operating system and its version and the architecture you are running.

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

Yes

Additional environment details

Additional environment details

Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

[vikas-goel]

/assign mheon

[l0rd]

@vikas-goel thank you for the feedback. Can you please be more specific about the scenarios supported when using the annotation, but not when using volumes of type image?

#23819 was intended to support the standard way to mount images inside containers (Kube image volumes) and deprecate the annotations mechanism since it's not supported by any Kube client other than Podman. However, there shouldn't be any loss of features. In particular, #23819 adapted the existing podman play with automount volume test to verify that both methods were able to mount an image.

[mheon]

@vikas-goel I missed this one when it went in, sorry. I'll bring it up with the team and see what we can do.

[vikas-goel]

Thanks @mheon. There is another that we discussed in the original discussion was that if a volume with same path exists in multiple volumes, then the last image in the order will take precedence.