What I can't do with Quadlets...

[kmpeterson]

(Many thanks in advance for any advice... and happy to be corrected if I'm missing something or I've misunderstood the project direction...)

I've developed an unpleasant gut reaction to managing a workflow that fires deprecation warnings. Specifically, I have a number of different containers and pods that are mostly singleton applications, and my original workflow since migrating to Podman 3 years ago has been to use podman generate systemd to have them managed by the host. But - warning! deprecation! (I do understand there aren't any current plans to drop the generate functionality.)

So, my specific issue is this: I have several applications where podman run is scripted to instantiate containers where I do things like set container IP addresses and specific image tags. For one of my applications, I started to work on using .build and .image unit files referenced by .container unit files, and I realized that I'm rather stuck by not being able to use variables the same way I can with scripted podman run or podman build commands. For example, an environment variable called VERSION allows me to pull and build images and containers with specific tags, which gives me a clear path to back out of a problematic deployment. I also have multiple instantiations of services that have unique IP addresses, health commands, and volume mounts, which are easy to loop around podman run with variables different for each container.

But systemd units don't support this. One can template an instance - so there is one and only one "variable" in a unit file, %i. Certainly it's fine to set environment files referenced that way, and I know about drop-ins and the like, but for actual parameters in unit files there's no way as far as I can determine to "vary" them. It's also the case where for development and testing I generally use podman run anyway - so I have more re-writing to do for a quadlet unit file, but this doesn't seem like that bad of a tradeoff.

I could, instead of scripting to generate podman run commands instead script generation of my unit files or a drop-in structure, but that doesn't seem much more efficient (I might do that if the podman generate systemd command was going to be dropped).

I don't know whether my use cases are that unusual, but I don't see a way around this limitation that doesn't raise the level of convolution. I'm wondering if anyone else has this issue and has a solution - or whether, for example, since these Quadlet unit files aren't directly processed by systemd (i.e., they go through their own generate process) any thought has been given to supporting environment vars in [Container], [Build], [Image], etc., section processing.

(For most of my applications I am using Quadlets successfully, except one or two big ones I've just updated that I'd like to see if I can bring into the fold.)

I appreciate your reading this far, and thanks for any thoughts.

[ygalblum]

Can you provide an example for how you currently use and set the environment variables (i.e. when using podman generate system)? I'm not sure I understand your need.
BTW would using systemd's Environment= or EnvironmentFile= in the [Service] section address your need?