Nemric
commented
1 year ago I did some work on that some month/years ago but after some tries and a new job I didn't continue to work on this subject but PR is still there ! You can see my work here https://github.com/coreos/ignition/pull/1303 and the topic here https://github.com/coreos/ignition/issues/1296 The main reason it has not been merged, I think, is because Systemd doesn't/didn't take care about presets when they are defined by early initialisation steps like ignition ... services are not started at all as far as I can remember
I'd like to "answer" to that link https://major.io/p/quadlets-replace-docker-compose/ you shared, to say that quadlet is not a replacement for compose but for "podman generate systemd" That way, quadlet is a systemd generator that provide systemd units "on the fly" and then, is always up to date with podman/quadlet changes made from systemd and podman collaboration without having to generate or write Systemd service units any more
The dependencies (e.g. : [Install] WantedBy=caddy.service multi-user.target default.target) are the same as systemd's dependencies, finally, only [Container] section is different from a service unit.
Reading Major's blog post on quadlet use with FCOS makes me think we have room for improvement to add some sugar for systemd --user. This is a killer way to run unprivileged container workloads and it would be nice to support specific users and the more global, administrative /etc/systemd/user/ section.
Has this come up before, and if not do you think this is worth adding? Sure, it's mostly possible today using files: but I think the native systemd: section would make it a much better user experience.
I think for per user support something like this could work for the spec (this is just chicken scratch) systemd-user
maybe if the individual user is left out, the global location could be used.
Thoughts?