Quadlet: Add support for --pod

[Doomsdayrs]

Feature request description

Podman supports clustering containers in a pod that helps isolate their networks and also share volumes and exposed ports.

Suggest potential solution

Adding Pod as an argument to [Container] would allow system administrators to cluster containers easily.

Have you considered any alternatives?

N/A

Additional context

No response

[rhatdan]

We have deviced up til now to concentrate pod efforts underneath the .kube support. There is a lot of complexity in supporting Pods under systemd, and we think people who want to work with pods should use kube.yaml.

[vrothberg]

I concur with @rhatdan. The .kube files should be used for Pod-specific use cases. Supporting pods otherwise would lead to something close to Kubernetes YAML, so I think it's best to not create something new.

@Doomsdayrs, are you familiar with the Kube functionality? Is something missing that you would like to see supported?

[arizvisa]

@Doomsdayrs, I've been using the PodmanArgs= backdoor to facilitate joining a quadlet container to a specific pod created outside of quadlet(5). Specifically, I'm using the --pod-id-file=%t/pod-whatever.pod-id" parameter, and --mac-address=... (since that's missing as well).

You can create a "Service" section in your quadlet container to assign Environment variables and then use them directly in PodmanArgs= sorta like:

[Unit]
...

[Container]
...
PodmanArgs=--pod ${CONTAINER_POD_NAME}

[Service]
Environment=CONTAINER_POD_NAME=podname
# or
EnvironmentFile=/path/to/environment/file/with/settings

Since PodmanArgs= ends up being used in ExecStart=, you can simply reference environment variables and systemd will expand them for you when starting the service. As noted in systemd.unit(5), you can also use dropins to augment the service unit. Using a dropin, you can use either Environment=, or EnvironmentFile= to assign any dynamically generated values that are necessary for executing the service. It's not elegant, like having a specific key to assign, but at least this way you won't be limited by quadlet's present capabilities.

Also, in some cases, it might be worth it to create your own systemd.generator(7) that uses dropins to extend your generated Container Unit. This way you can add a custom section (such as [X-ContainerExtraOptions]), include your own keywords, and then your generator can use them to produce a dropin that that modifies said Container Unit.

I went the systemd.generator(7) route for Volume Units in order to add another RequiresMountsFor= dependency (via a pretty terrible shellscript). If you want to go this route, your generator script takes 3 parameters that are directories, and its only job is to write units/dropins, make directories, and add symbolic links to one of those 3 parameters. To deploy it, you can just store your script under /etc/systemd/system-generators.

[ygalblum]

@arizvisa please note that Quadlet is a systemd.generator. I'm not sure and couldn't find in the man page anything about the processing order of the generators. So, I'm not sure if there is a way to guaranty that one generator runs before the other.
As for unsupported keys, this is the reason we added the PodmanArgs key. This allows users to extend the command line even if Quadlet does not have a dedicated key for it.

[arizvisa]

@ygalblum

@arizvisa please note that Quadlet is a systemd.generator. I'm not sure and couldn't find in the man page anything about the processing order of the generators. So, I'm not sure if there is a way to guaranty that one generator runs before the other.

It's definitely in the manpages that there's no guarantee on the order that generators will be executed as they are intended to be executed in-parallel. However, since quadlet(5) is not creating dropins for the relevant service, there is zero conflict.

Are there plans in the future for quadlet(5) to generate dropins from its unit search path? Personally, it'd be great to separate keys that can be specified multiple times from a container unit before its service gets generated, but it seems like a strange thing to implement considering quadlet(5) controls the contents of the entire service unit anyways.

As for unsupported keys, this is the reason we added the PodmanArgs key. This allows users to extend the command line even if Quadlet does not have a dedicated key for it.

Yep. It's a good thing you had the foresight? </sarcasm> To be clear, that was what my reply was intending to demonstrate to the OP after it was suggested to consider Kube units as an alternative.

[Luap99]

I think this was fixed in #20762

[Doomsdayrs]

@Luap99 I am a bit confused

It was merged into master, but no changelog mentions it?

Fedora 39 has v2.8.1, which should contain the commit, but man does not show the change?

[rhatdan]

We now support [Pod] section in Quadlet.

[ygalblum]

@Doomsdayrs the PR for adding the support for .pod files and the Pod key in .container files missed the cutoff date for 4.8 and as a result will be released only in the following release (new features are not added to patch releases)