voxpupuli / puppet-systemd

Puppet module to manage systemd
https://forge.puppet.com/puppet/systemd
Apache License 2.0
52 stars 142 forks source link

Add support for podman quadlets #474

Closed dabelenda closed 1 day ago

dabelenda commented 5 days ago

Pull Request (PR) description

This PR adds support for podman Quadlets, a generator for systemd that creates units automatically for files in a specific folder.

Tested with a kube Yaml file and it starts the pod.

traylenator commented 5 days ago

I'd been thinking about doing this.

If this was going to be done I would at least steal the types I added in https://github.com/southalc/podman/pull/83 so the contents of the quadlet files can be managed.

But I question if managing quadlets should be in here at all. These are not unit files processed by systemd. Having said that its easy place to have them and it will not intrude into systemd configuration.

I think a seperate quadlet module using as much of this module as possible would make more sense? Which I'm very happy to work on lifting much of what I did above. Result is somewhat we ignoring the existing podman module but that is fine for the sake of actual progress.

dabelenda commented 5 days ago

@traylenator at least for unit_files this module does not manage the content of the files.

All type definitions and templating were created for the dropins. I copied the behavious of the unit_file.pp for everything which is why I did not add types.

I am also unsure if this is the correct spot for this, which is why I did not go all the way, like creating tests and managing the content of the quadlet files.

ekohl commented 5 days ago

Like @traylenator I question it. It's not systemd, but podman. And even with podman you need a new version (4.4+ for basic support, which Debian 12 doesn't even have, newer for the more advanced features).

Given the lack of progress on https://github.com/southalc/podman/pull/83 I wouldn't mind taking over that module. Ideally transferring but forking if needed.

traylenator commented 5 days ago

https://github.com/southalc/podman/pull/83 I wouldn't mind taking over that module. Ideally transferring but forking if needed.

It may actually be easier to start again with a puppet-quadlets module. The southcalc/podman has a load of very necessary at the time hard to do stuff which all becomes unnecessary with simplicity of quadlets. My preference would be new module rather than migration but I would happily work on either.

ekohl commented 5 days ago

I currently don't use the podman module, but I can see how quadlets replace many of the old ways. A puppet-quadlets module sounds like a good plan to me.

TheMeier commented 4 days ago

To me it is also not really clear to which domains really belong. Podman? Systemd? I tend more towards podman, thats also where its code is now.

dabelenda commented 4 days ago

I agree this is a bit fuzzy in terms of scope, the generator for quadlet is in the podman package. At the same time, there are generators for a bunch of "core" features of podman, like mount points, etc.

An additionnal puppet module for quadlets that installs podman, manages the content of quadlet files, might be a good thing. Will the new module depend on puppet/systemd for management of daemon-reload or things like that? Will the module contain its own logic for managing service like puppet/systemd ?

Conceptually the two modues will be pretty similar in features I think.

TheMeier commented 4 days ago

If there is going to be a new module, I think it should re-use whatever it can from the systemd module

traylenator commented 4 days ago

If there is going to be a new module, I think it should re-use whatever it can from the systemd module

Yes of course it would use systemd::user_service , systemd::daemon_reload for instance.

@dabelenda sounds like we have a plan. Unless more comment in next day or two I'll create repo puppet-quadlets and we can plan it out in an issue.

traylenator commented 2 days ago

Add quadlet support in own module. - https://github.com/voxpupuli/puppet-quadlets/issues/1

dabelenda commented 1 day ago

Closing this PR since we agree that going for another module is the correct path.