Kube Play - Add support for image based volumes

[ygalblum]

Feature request description

As of 1.31, Kubernetes supports image based volumes (as Gated Featured). Since Podman already supports it in run and also via annotations, it should also support it in the K8S YAML file.

Suggest potential solution

If a K8S Yaml is played with a volume of type image, Podman should support it

Have you considered any alternatives?

Users have other alternatives such as annotations or creating volumes based on images. But, this requires changing the K8S Yaml file which Podman tries to avoid

Additional context

No response

[ygalblum]

Supporting image volumes in kube play is fairly strait forward since it is already supported in run. There is one issue I am not sure if Podman should address. In K8S, the image volume structure allows the user to set the PullPolicy. However, due to separation of concerns, Podman does not pull images configured as volumes and instead expects them to be locally available. Should Podman implement it? WDYT

[Luap99]

Podman does not pull images configured as volumes and instead expects them to be locally available. Should Podman implement it? WDYT

It should be simple to pull base images based of the policy in the play kube code path somewhere before handing to the specgen/libpod volume checks that expect the image to be present so I think we should do it. Especially if one is only using kube yaml not pulling the image there would mean they have to use a separate command first to pre pull.

[ygalblum]

Especially if one is only using kube yaml not pulling the image there would mean they have to use a separate command first to pre pull

I agree. But, I had a similar discussion with @vrothberg when I wanted to create image based volume and this is why the Qualdet .image files came to life. That's why I wanted to hear different opinions.

[Luap99]

I think the argument was mainly around having to all the typical pull options, tsl-verify, authfile, etc.... Given kube play already has these options and already does pull images I see no problem letting it pull images as well.

[ygalblum]

I guess that both yes and no. Yes, because this was the argument when we discussed volume creation. No, because currently automatic image pulling is only supported for the running container image. In podman run using --mount with an image requires the image to exist locally. Similarly, in kube play mounting images is currently supported via annotations and again, the image has to exist locally.

But, I feel like I'm making someone else's points, since I agree with your view :).

Now, regarding implementation, as you wrote, pulling the images seems easy to implement. The same function used for the container image can be used with some minor changes. My problem is with the automatic update process.

IIUC the code knows how to get the list of images needed to be updated from the list of containers returned by the runtime and labels set on them. However, I could not find a similar mechanism for images used as volumes. Do you know of such a mechanism in the code that you can point me to?

[Luap99]

IIUC the code knows how to get the list of images needed to be updated from the list of containers returned by the runtime and labels set on them. However, I could not find a similar mechanism for images used as volumes. Do you know of such a mechanism in the code that you can point me to?

Are you talking about podman auto-update?

[rhatdan]

podman kube play KUBE.YAML Should just work, if kube would trigger CRI-O to do the right think and pull the volume image, then podman should do the same. The discussion of quadlets should not effect this decision.

.Image should not come into play.

[ygalblum]

@Luap99 IIUC then yes. Because if Podman supports the PullPolicy field for volumes then something needs to keep track of these images.

@rhatdan Quadlet came into the discussion not because it is part of the flow here but because a similar discussion regarding separation of concern was held back then.

I already have the code that supports defining images as volumes. There are two open questions:

1. Should kube play pull the image if it is not there? I think there is an agreement that we want to support it. The process will use the same authentication credentials it uses for the container images.
2. Should kube play have a full support of the PullPolicy key via auto-update?

[Luap99]

Should kube play have a full support of the PullPolicy key via auto-update?

I still don't quite follow. if the policy is set to always it would juts pull any time the unit is restarted. Or do you actually want to make auto-update check for new volume images and then restart the unit even when the container image didn't changed?

I think the later is not really required to implement this feature and could be added later if users actually want it.

[rhatdan]

I would think Auto Update only checks if the primary application image is updated, For now, we should just reply on pulling volume images when the service is restarted.

[ygalblum]

OK, fine by me. Just wanted to make sure we're all in agreement