`podman kube play` support for data volume container `podman run --volume-from`

[vikas-goel]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

We have a use-case of data volume container where such containers are created but never started. The volumes of these containers are then bind mounted to an application container using --volumes-from option. Docker Compose supports this deployment. In order to move to Podman kube, we need this use-case supported.

Does podman kube play support it?

[rhatdan]

Would an init container work for this use case? I think they would get started, but you could simply have them exec /bin/true.

[rhatdan]

But wouldn't it be better to just define the volumes in the kube yaml?

[vikas-goel]

The data volume container images do not contain any runtime environment. So, exec to sh/true will fail.

If we were to specific the volumes in the YML, then those data volume containers need to be created, inspect their volumes and then specify in the YML.

Whereas, with Docker Compose I can specify the application and data volume containers all in the same YML with service dependencies setup in there itself. The Docker Compose can just create (not start) the data volume containers and bind mount all the volumes to the application container.

I am looking for equivalent in podman kube.

[rhatdan]

Podman kube uses kubernetes.yaml so the equivalent would be how kubernetes handles volumes. There is nothing specific about podman use of kubernetes.yaml.

With k8s volumes there is no need to specify a container with a volume. But maybe I don't under stand, are you saying that a container image comes with data stored in its image that other containers they use?

Could you point at an example of a "volume container"?

[vikas-goel]

I understand your point of k8 yaml and volumes. My use case is more of general available podman run --volumes-from that we are able to manage using the Compose yaml. In order to move away from Compose to 'podman kube', we will need this capability.

There are a variety of use cases for the data volume container image. For example, one use case is to bundle the orchestration scripts for life cycle management of the containers. The other being bundling some (on-demand, out-of-band) plugins such as some library files to extend the capability of an application without having to recreating the application image for every such use-case.

[rhatdan]

Well we can not directly change the kubernetes.YAML file in a way that would break k8s. We could add ANNOTATIONS, which we have added in the past and then make podman kube play work differently when it sees these annotations.
But that would probably mean you Kubernetes YAML files would only work with Podman.

[rhatdan]

Look for annotations mentions in the podman kube play man page.

[vikas-goel]

Use of annotation and restriction to Podman environment are absolutely fine. To reiterate the use-case,

1. A data volume container image, that may consist of script, .so libraries etc., is built from SCRATCH. There is no runtime environment inside the image. The container image may have or more volumes. A container of this image is created but never run. The volumes of the image are setup (copy-up) when the container is created.
2. An application container image that has application bundled in it.
3. A Podman kube YML file that has definition of both the application container and data volume container. When the YML is used to run podman kube play, all the volumes of the data volume container are attached to the application container in read-only (or rw) mode as specified.

[rhatdan]

I wonder if an image volume would help with this. Currently Podman supports image volumes, which is somewhat similar.

[vikas-goel]

Is there a sample podman kube YML file for the image volumes that satisfies the use case?

[vikas-goel]

Is there an update?

[github-actions]

A friendly reminder that this issue had no activity for 30 days.