quadlet: Support for pods?

[runiq]

I haven't found anything to the point on the issue tracker or in discussions, so I was just wondering if adding support for setting up pods via quadlet was something the Podman team would consider. I really like the bit of abstraction pods provide.

[vrothberg]

Pods are already supported by using Kubernetes YAML, see https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html#kube-units-kube.

[ygalblum]

I also agree that adding support for a Pod will be very beneficial. Having said that, I do not agree that it is not "any different from network, volume or image units".

These three units handle only the creation of the corresponding Podman resource (volume, network or image). As a result, they have a clear dependency path: .kube and .container depend on them (and also .volume can depend on .image). However, for Pods, I see a more complex dependency path that I am not sure how to resolve.

The simple solution is to have a .pod unit for creating pods and allow .container units to depend on them in the same manner as they can depend on these units. However, pods have additional commands, mainly start and stop.

Once there is a service representing a pod, users will expect to be able to start, stop and restart the pod via this service and not the container specific one. Furthermore, what monitors the containers within the pod? What is the expected behavior from systemd regarding the .container unit when the pod is stopped?

One way I can think of is to define a new .pod unit that requires a single [Pod] section and multiple [Container] sections (The latter will require additional design since the unit file schema does not allow it). Then, Quadlet will have the create lines (of the pod and the containers) as ExecStartPre lines while the ExecStart and ExecStop will call upon the pod.

I'm not sure if my suggestion works or not, but I think something like this is the path for it.

To summarize, I'm not against adding this support, I just think it's more complicated than that.

[vrothberg]

@ygalblum, we have a precedent in podman generate systemd --new $pod. There is one main .pod unit and separate .container units, one for each container in the pod. The .pod's main PID is the one of the infra container.

That should translate fairly easily into Quadlet by adding a .pod file. .container units can join the pod via Pod=$pod-name.

The output of generate systemd --new $pod with a simple alpine top container looks as follows:

# pod-502637071c7e2ad41d1fc460fee1c887ee4dc1eb723f56ce78b44ee386309502.service
# autogenerated by Podman 4.7.2
# Tue Nov 21 10:01:20 CET 2023

[Unit]
Description=Podman pod-502637071c7e2ad41d1fc460fee1c887ee4dc1eb723f56ce78b44ee386309502.service
Documentation=man:podman-generate-systemd(1)
Wants=network-online.target
After=network-online.target
RequiresMountsFor=/run/user/1000/containers
Wants=container-76add2f360ffa86f76954b9ed098fd266b67581775a3d4453665dc1bc206b399.service
Before=container-76add2f360ffa86f76954b9ed098fd266b67581775a3d4453665dc1bc206b399.service

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStartPre=/usr/bin/podman pod create \
	--infra-conmon-pidfile %t/pod-502637071c7e2ad41d1fc460fee1c887ee4dc1eb723f56ce78b44ee386309502.pid \
	--pod-id-file %t/pod-502637071c7e2ad41d1fc460fee1c887ee4dc1eb723f56ce78b44ee386309502.pod-id \
	--exit-policy=stop \
	--name=123 \
	--replace
ExecStart=/usr/bin/podman pod start \
	--pod-id-file %t/pod-502637071c7e2ad41d1fc460fee1c887ee4dc1eb723f56ce78b44ee386309502.pod-id
ExecStop=/usr/bin/podman pod stop \
	--ignore \
	--pod-id-file %t/pod-502637071c7e2ad41d1fc460fee1c887ee4dc1eb723f56ce78b44ee386309502.pod-id  \
	-t 10
ExecStopPost=/usr/bin/podman pod rm \
	--ignore \
	-f \
	--pod-id-file %t/pod-502637071c7e2ad41d1fc460fee1c887ee4dc1eb723f56ce78b44ee386309502.pod-id
PIDFile=%t/pod-502637071c7e2ad41d1fc460fee1c887ee4dc1eb723f56ce78b44ee386309502.pid
Type=forking

[Install]
WantedBy=default.target
# container-76add2f360ffa86f76954b9ed098fd266b67581775a3d4453665dc1bc206b399.service
# autogenerated by Podman 4.7.2
# Tue Nov 21 10:01:20 CET 2023

[Unit]
Description=Podman container-76add2f360ffa86f76954b9ed098fd266b67581775a3d4453665dc1bc206b399.service
Documentation=man:podman-generate-systemd(1)
Wants=network-online.target
After=network-online.target
RequiresMountsFor=%t/containers
BindsTo=pod-502637071c7e2ad41d1fc460fee1c887ee4dc1eb723f56ce78b44ee386309502.service
After=pod-502637071c7e2ad41d1fc460fee1c887ee4dc1eb723f56ce78b44ee386309502.service

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStart=/usr/bin/podman run \
	--cidfile=%t/%n.ctr-id \
	--cgroups=no-conmon \
	--rm \
	--pod-id-file %t/pod-502637071c7e2ad41d1fc460fee1c887ee4dc1eb723f56ce78b44ee386309502.pod-id \
	--sdnotify=conmon \
	-d alpine top
ExecStop=/usr/bin/podman stop \
	--ignore -t 10 \
	--cidfile=%t/%n.ctr-id
ExecStopPost=/usr/bin/podman rm \
	-f \
	--ignore -t 10 \
	--cidfile=%t/%n.ctr-id
Type=notify
NotifyAccess=all

[Install]
WantedBy=default.target

[ygalblum]

@vrothberg thanks for this. I'll look into it

[vrothberg]

Thanks, @ygalblum ! Looking forward to seeing this in action

[drewlsvern]

#20851

[ant-bl]

Hello

I have the same issue as stiletto. I don't know if it is the right place to write it. If it is not, feel free to show me the proper place.

In my use case I run the airflow images in user mode (https://airflow.apache.org/docs/apache-airflow/stable/howto/docker-compose/index.html) witch run using the airflow user with the uid 50000 and the root gid 0. I must share a volume between the multiple images and I want to remap the uid 50000 to my user id and the group root id (0) to my group id. As it is not possible to create a user namespace per container, I create a pod, remapping the uid using --uidmap and --gidmap. I can't use the option --userns=keep-id:uid=MYUID,gid=0 because this option does not accept to remap the root gid.

And kube play does not support these 2 options : podman play kube (and this quadlet) has no support for uid/gid mapping #16594

podman pod create \
    --uidmap 0:1:50000 \
    --uidmap 50000:0:1 \
    --uidmap 50001:50001:15536 \
    --gidmap 0:0:1 \
    --gidmap 1:1:64535 \
    --publish 8080:8080 \
    --publish 5555:5555 airflow

[ygalblum]

Support for .pod files was added here: #20762.

Since we missed the cutoff date for 4.8, the feature will be added as part of 4.9.

To speed up adding the feature, I first only added support for PodName and PodmanArg which allows setting all the arguments. Hopefully support for additional keys will be added until the feature is released.

@rhatdan @vrothberg Should we close this discussion?

[drewlsvern]

@ygalblum Thank you so much for adding this feature so quickly. I tested this out last night and it works great. I just have one question, as there does not appear to be support for Network at the moment, I'm wondering what the recommended approach would be for this.

Perhaps just manually create a network and assign it via PodmanArgs ?

[Pod]
PodName=mypod
PodmanArgs=-p 8000:80 --network=my-manually-created-network (can't set a .network file this way though it seems.)

[vrothberg]

Yes, I think that's a good way to add a network.

Can you open an issue to ask for a Network field in .pod. I think we can add more fields as needed.

[ygalblum]

As Valentin wrote, yes, this is the way you can do this currently.

My idea was to add the support for the .pod files as quickly as possible and add support for more keys as we go along. Seeing you comment, I realize that supporting the Network key is one of the more important ones since it also allows linking with .network files. I'll try to add the support in the next few days.

[vrothberg]

Yes, let's close the discussion.

Thanks a ton for @ygalblum to nail the implementation down so quickly in #20762. In case anybody finds issues or has further feedback, please open a separate issue.