In short: quadlet is a systemd generator which makes it easy to define container options in simple systemd-style config file, from which corresponding systemd units are created on the fly.
This seems like an ideal way to manage single-node (or otherwise stand-alone) container setups. Right now, I'm using a bunch of files created with `podman generate systemd`, and while that works, it's also kind of a management mess.
See https://blogs.gnome.org/alexl/2021/10/12/quadlet-an-easier-way-to-run-system... for an intro post and the project at https://github.com/containers/quadlet.
Smooge has packaged this into the main repo -- Rawhide but F36 build coming soon.
I propose:
1. We include this in the base ostree package set.
2. We document it as the primary way to set up containers on Fedora IoT for single / independent systems.
3. We provide feedback to the project on how this could serve real-world use cases better.
What do you all think?
I like this idea, but maybe we should just wait (or even help push) for the upstream podman integration (https://github.com/containers/quadlet/issues/11)?
On Fri, May 6 2022 at 03:40:35 PM -0400, Matthew Miller mattdm@fedoraproject.org wrote:
In short: quadlet is a systemd generator which makes it easy to define container options in simple systemd-style config file, from which corresponding systemd units are created on the fly.
This seems like an ideal way to manage single-node (or otherwise stand-alone) container setups. Right now, I'm using a bunch of files created with `podman generate systemd`, and while that works, it's also kind of a management mess.
See https://blogs.gnome.org/alexl/2021/10/12/quadlet-an-easier-way-to-run-system-containers/ for an intro post and the project at https://github.com/containers/quadlet.
Smooge has packaged this into the main repo -- Rawhide but F36 build coming soon.
I propose:
We include this in the base ostree package set.
We document it as the primary way to set up containers on Fedora
IoT for single / independent systems.
- We provide feedback to the project on how this could serve
real-world use cases better.
What do you all think?
-- Matthew Miller <mattdm@fedoraproject.org mailto:mattdm@fedoraproject.org> Fedora Project Leader _______________________________________________ IoT mailing list -- iot@lists.fedoraproject.org mailto:iot@lists.fedoraproject.org To unsubscribe send an email to iot-leave@lists.fedoraproject.org mailto:iot-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/iot@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Fri, May 06, 2022 at 08:24:07PM -0400, Andy Thurman wrote:
I like this idea, but maybe we should just wait (or even help push) for the upstream podman integration (https://github.com/containers/quadlet/issues/11)?
As I understand it, I think any integration will be fairly transparent from a user point of view.
The generator has to run in pretty limited environment so proably won't be part of the podman binary... I think it might end up refactored and pulled into podman as a project but it should stay fundamentally the same kind of thing.
In short: quadlet is a systemd generator which makes it easy to define container options in simple systemd-style config file, from which corresponding systemd units are created on the fly.
This seems like an ideal way to manage single-node (or otherwise stand-alone) container setups. Right now, I'm using a bunch of files created with `podman generate systemd`, and while that works, it's also kind of a management mess.
See https://blogs.gnome.org/alexl/2021/10/12/quadlet-an-easier-way-to-run-system... for an intro post and the project at https://github.com/containers/quadlet.
Smooge has packaged this into the main repo -- Rawhide but F36 build coming soon.
I propose:
We include this in the base ostree package set.
We document it as the primary way to set up containers on Fedora IoT for single / independent systems.
We provide feedback to the project on how this could serve real-world use cases better.
What do you all think?
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? 2) is it something we ship by default or support by it being easy to overlay for users that want it 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) 4) 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).
P
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. :)
On Wed, May 11, 2022 at 11:47:04AM -0400, Matthew Miller wrote:
It's in Rawhide. Smooge made a F36 build but didn't put out a bodhi update ... I'm pinging him on that now. :)
Update: FEDORA-2022-f18c2c73a5 -- thanks smooge. :)
-
Andy Thurman -
Matthew Miller -
Peter Robinson