Systemd and Overriding vendor settings feature

[Yanis Guenane]

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

[Trevor Vaughan]

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

--
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.
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 --

[Yanis Guenane]

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

[Trevor Vaughan]

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

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.