Hey Trevor,
Thanks for the answer. I haven't thought about a systemd native type, I
understand the need for it (ie. against cluttering the service type) and it
seems like a reasonable path to go down.
However, I do have a concern with this solution over the service type one.
It is that puppet modules will need to be updated to include user to input
some systemd configuration.
So both a $systemd_options and create_resources('systemd',
$systemd_options) will be needed in every modules for user to be able to
specify them.
As you stated above, the same pattern might apply based on different init
system, leading to cluttering the modules themselves. What would you
recommend ?
On the other hand, I - unfortunately - don't see any simple/elegant way to
provide the feature this thread is about.
--
Yanis Guenane
On Saturday, March 14, 2015 at 8:59:53 PM UTC+1, Trevor Vaughan wrote:
>
> Hi Yanis,
>
> I think that better systemd management should be available. However, I
> think that it should be provided via a specific systemd native type instead
> of service.
>
> The systemd native type can use autonotify to prod the associated service
> on restart.
>
> My reasoning here is that the service type collects a specific, common,
> set of functionality across all service providers. What you are
> indentifying is the configuration file portion of a particular service. If
> you attempted to provide all of these options for everything in init,
> upstart, and systemd (and others!) in the 'service' type, it would become
> insanely cluttered and complex.
>
> Thanks,
>
> Trevor
>
> On Sat, Mar 14, 2015 at 2:22 PM, Yanis Guenane <ygue...@gmail.com
> <javascript:>> wrote:
>
>> Hi all,
>>
>> Systemd offers an interesting feature that is Overriding vendor
>> settings[1].
>> This consists of creating a file called
>> /etc/systemd/system/MYSERVICE.service.d/ALEATORY.conf
>> which will only include the bits one wants on top of the vendor settings
>> (making upgrades of package
>> relatively easy while keeping the overridden bits intact).
>>
>> Taking MySQL for example one could :
>>
>> * Specify the ExecStart to contain --wsrep-new-cluster to start a
>> Galera cluster
>> * Change file limits specifying LimitNOFILE
>> * Change the TimeoutSec value to timeout sooner
>> * etc...
>>
>> With some major Linux OSes moving to systemd I do think this would be a
>> nice to have feature.
>>
>> I tend to think that if the community agrees with the aforementioned
>> feature it belongs
>> to the systemd provider at the resource level. Else it would need to be
>> implemented at the
>> module level. If so, should we try to define a pattern that people can
>> use in their module,
>> so modules users can have a consistent way of doing it ?
>>
>> To summarize in two questions :
>>
>> * Do you think Overriding vendor settings feature from systemd should
>> be handled via Puppet ?
>> * If yes, do you think it belongs to the resource level of the module
>> level ?
>>
>> Thank you all and have a great week end,
>>
>> [1] http://www.freedesktop.org/software/systemd/man/systemd.unit.html
>>
>>
>>
>>
>>
>> --
>> Yanis Guenane
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to puppet-dev+...@googlegroups.com <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-dev/6dbc82a0-c327-48ab-b246-38c6d86e8b56%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/puppet-dev/6dbc82a0-c327-48ab-b246-38c6d86e8b56%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699
> tvau...@onyxpoint.com <javascript:>
>
> -- This account not approved for unencrypted proprietary information --
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/57c83490-5894-4a21-b499-cb1cd3fd3d57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
