It seems like this is a composition problem and suited for a Profile.
For instance:
class apache {
service { 'apache': ensure => 'running' }
}
Is all that the 'apache' module should provide. Any override that you wish
to have is an artifact of your local configuration.
So, you could have a web_server Profile that does the following:
profile web_server {
include 'apache'
systemd_service { 'apache': limit_nofile => '200' }
}
You could also use create_resources if you like but I find that it makes
things difficult to debug except for items that are exceptionally clear
(like yumrepos).
Thanks,
Trevor
On Sat, Mar 14, 2015 at 5:00 PM, Yanis Guenane <[email protected]> wrote:
> 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 <[email protected]> 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 [email protected].
>>> 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
>> [email protected]
>>
>> -- 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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/57c83490-5894-4a21-b499-cb1cd3fd3d57%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-dev/57c83490-5894-4a21-b499-cb1cd3fd3d57%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
[email protected]
-- 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoU%3DbPM1wfbaJ%3D0Yj2%3DsKNMTL1Yr8yhu_H4ydBCmQEsbVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
