It would be nice if this module would use puppet-systemd for service and snippet configuration.

[psychonaut]

There is a great module https://forge.puppet.com/modules/puppet/systemd/readme which does exactly what you have implemented in the module. It would really help us to avoid issues like:

Duplicate declaration: File[/etc/systemd/system/vector.service.d] is already declared at (file: …/internal_qa/modules/vector/manifests/configure.pp, line: 38); cannot redeclare (file: …/internal_qa/modules/systemd/manifests/dropin_file.pp, line: 52) (file: …/internal_qa/modules/systemd/manifests/dropin_file.pp, line: 52, column: 5)

[jhbigler]

Thanks for the suggestion @psychonaut, and apologies for the late response. I try to reduce dependencies outside of stdlib if I can help it - I don't have a ton of time to devote to this module, so reducing dependencies makes life much easier. But, that module probably does do a better job of managing dropins than this module does.

I see a few options:

1. Use that module directly for managing all systemd-related files. Downside is, I have to keep track of changes in that module, be aware of any breaking changes, etc
2. Copy what that systemd module does for its systemd::dropin_file defined type and leverage the ensure_resource function to make sure the /etc/systemd/system/vector.service.d directory exists, without always creating the directory if the user doesn't use this module's defined type. I think that's the issue at hand for you, where this module always creates that directory even if its dropin defined type is not being used
3. Introduce a way to turn off maintenance of systemd dropin-related resources in this module entirely

I'll put in some thought. Thanks for making me aware of this

[optiz0r]

I can't see that the current code does a system daemon-reload after changing the systemd dropins either, which is something else that the systemd module would handle automatically.

I just switched from using a simple in-house module doing the typical package->file->service pattern to using this module, which has otherwise gone well (thanks for the work you've done here!), but ran into a problem where the service was failing to restart because it hadn't reloaded the systemd unit, which I'll work around outside this module in the interim.