Multiple containers? (pods)

[xeor]

Would it make sense to add support for multiple containers in the same format as well? I would like to replace podman-compose with something like this

[rhatdan]

I think this would be a POD. Or do you just want to link namespaces together?

[xeor]

Linking namespaces, like -t identity. Usecase would be if i have an app with a separate redis container. Wouldn't be that hard to manage now, but the usecase extends to having multiple of these environments at the same node

[alexlarsson]

So, you mean like two different .container files, but linked? Or do you mean one .container file with like NumInstances=2?

[xeor]

The first.. I'm not sure the second make that much sense on a single node setup..

[alexlarsson]

I guess you can already do instancing using systemd if you name the file foo@.container, which will generate foo@.service, which systemd sees as a template. Then you can systemctl start foo@1.service foo@2.service.

[alexlarsson]

When you say "linked", do you mean having a port from the redis container available in the app container, or do you mean full network namespace sharing, like --network=container:systemd-redis.

[rhatdan]

@alexlarsson currently podman generate systemd does not handle Pods, should this be something that quadec could handle.

I would see sharing of network namespace, pid, IPC namespaces useful in general, but maybe not expose them individually but as a POD.

[alexlarsson]

Yeah, having some pod support would be cool.

One thing that is somewhat iffy is the cgroup side of things. Quadlet uses a split cgroup, so that the podman cgroups go beneath the .service cgroup, and that is never gonna work with a pod that has its own cgroup.

However, I think its possible to set up a pod that shares everything except the cgroup. Ten we could automatically create a systemd scope for the pod, and put the services under the pod scope, which would group them in the cgroup hierarchy anyway.

[alexlarsson]

Eh, I meant a slice, not a scope

[rhatdan]

Can't we put the pod cgroup under the systemd cgroup? I guess as long as all of the container processes in the pod are in the same cgroup, then that would work.

[alexlarsson]

What i mean is that the cgroup hierarchy looks like this:

 /system.slice/quadlet-redis.service
     ├─container
     │ ├─1684730 /dev/init -- docker-entrypoint.sh redis-server
     │ └─1684797 "redis-server *:6379"
     └─supervisor
          └─1684726 /usr/bin/conmon --api-version 1 ...

Suppose you have two services. They would be in /system.slice/foo.service/container and in /system.slice/bar.service/container. You can't insert the "pod" cgroup dir under foo.service, because then the bar.service dir would not be in it.

However, if you set Slice=system-podA.slice in the service file you get this cgroup:

/system.slice/system-podA.slice/quadlet-redis.service
       ├─container
       │ ├─1685384 /dev/init -- docker-entrypoint.sh redis-server
       │ └─1685457 "redis-server *:6379"
       └─supervisor
           └─1685380 /usr/bin/conmon --api-version 1 ...

Which is essentially what you want, its just that systemd created the /system.slice/system-podA.slice, rather than podman.

@giuseppe I think we talked about this, right. If i pass --cgroups=split for a container in a pod then podman ignores the cgroup for the pod, right?

[giuseppe]

@giuseppe I think we talked about this, right. If i pass --cgroups=split for a container in a pod then podman ignores the cgroup for the pod, right?

yes, --cgroups=split is supposed to use the current cgroup

[trusch]

Is this something that is still considered? I'd love to see this feature being supported since having pods is kind of a unique selling point for podman in general and having that exposed with a nice API through quadlet would be fantastic.

[rhatdan]

We are supporting Pods only via the new kubelet support. See in Podman since quadlet has been merged.