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 <yguen...@gmail.com> 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 <ygue...@gmail.com> 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.
>>> 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
>>
>> -- 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
> <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
tvaug...@onyxpoint.com
-- 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/CANs%2BFoU%3DbPM1wfbaJ%3D0Yj2%3DsKNMTL1Yr8yhu_H4ydBCmQEsbVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
