On Wed, May 11, 2022 at 09:19:53AM +0100, Peter Robinson wrote:
Overall I'm fine with it. My general thoughts are:
1) 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 \
--label "io.containers.autoupdate=registry" \
--group-add keep-groups \
-p 8092:8092 \
... 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.
2) 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
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.)
3) 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. :)
4) Do we ship it straight up once it's in Fedora, wait until
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. :)
Fedora Project Leader