On Wed, May 11, 2022 at 09:19:53AM +0100, Peter Robinson wrote:
Overall I'm fine with it. My general thoughts are:
- What value does it provide to the average user over the build int
podman bits to generate systemd services?
A lot. Well, three key things:
1. The `podman generate systemd` command is basically: "run once and then you have a starting point". Sometimes the generated file can be used as-is, but it might need tweaking. Which then, if your tweaks are extensive, becomes complicated to maintain, particularly because best practices for running podman containers via systemd keep changing. There's no way to sync your customizations with whatever changes a fresh `podman generate systemd` would bring.
By contrast, quadlet lets you set what you want intentionally, separating the specific [Container] section from generic systemd config sections which are passed on as-is.
This could even be helpful for containers that we might someday ship as part of Fedora IoT itself (or someone's derived version). Of course the 'final' systemd units could be shipped, but then if there's a new podman version with new features (or incompatibilities!) those units would need to each be manually updated. The generator approach would be both backwards and forwards compatible.
2. The generated systemd units end up with really long `podman run` command lines, with all of the options there. This is hard to work with. For exmple, mine from zigbee2mqtt:
ExecStart=/usr/bin/podman run \ --cidfile=%t/%n.ctr-id \ --cgroups=no-conmon \ --rm \ --sdnotify=conmon \ --replace \ --detach \ --label "io.containers.autoupdate=registry" \ --name=zigbee \ --group-add keep-groups \ --network=slirp4netns:allow_host_loopback=true \ --device=/dev/serial/by-id/usb-1a86_TubesZB_971207DO-if00-port0:/dev/zigbee:rw \ --volume=/home/mattdm/hass/zigbee:/app/data:Z \ -p 8092:8092 \ docker.io/koenkk/zigbee2mqtt:latest
... almost 500 characters, and that's far from the worst it could be.
With quadlet, the same things would need to be configured, of course, but they're organized by key-value config — a lot easier to see, manage, comment out, etc.
3. I have not tested this, but it seems to have functionality to run containers as non-root _from the system-wide config_. As of right now, the units podman generates don't work for that. (You _can_ use them as systemd user units, but within/under a user account.)
I'm actually not sure what the best model is for Fedora IoT — there's some appeal to me to having it all run under a dedicated non-root user. (Thoughts?)
- is it something we ship by default or support by it being easy to
overlay for users that want it
Right now, we don't have a suggested approach to running and managing containers on individual/isolated ("not kubernetes") devices. We've got some good basic stuff https://docs.fedoraproject.org/en-US/iot/container-support/ on how to run podman, but it doesn't go beyond that.
I think this is — if not yet the perfect solution — on the path to being the right one. So I think we should ship it by default. (Also: it's quite small — 50k binary rpm.)
- I tried to test it via overlay and it doesn't appear to be in
Fedora (didn't look any further to see if it was under review etc)
It's in Rawhide. Smooge made a F36 build but didn't put out a bodhi update ... I'm pinging him on that now. :)
- Do we ship it straight up once it's in Fedora, wait until it's
integrated/part of podman, support it as overlay initially and include it once it's part of podman (you get the gist).
I think the user experience shouldn't change much even if it's integrated, so I don't think we need to wait. And it's not very disruptive for people who don't want to use it. I'm excited enough about it to draft an F37 change if it's helpful. :)