| author | ymh <ymh.work@gmail.com> |
| Fri, 14 Oct 2016 01:02:10 +0200 | |
| changeset 329 | 0a2c2ad49d75 |
| parent 28 | b0b56e0f8c7f |
| child 406 | cf0f23803a53 |
| permissions | -rw-r--r-- |
# == Class: elasticsearch::service # # This class exists to coordinate all service management related actions, # functionality and logical units in a central place. # # <b>Note:</b> "service" is the Puppet term and type for background processes # in general and is used in a platform-independent way. E.g. "service" means # "daemon" in relation to Unix-like systems. # # # === Parameters # # [*ensure*] # String. Controls if the managed resources shall be <tt>present</tt> or # <tt>absent</tt>. If set to <tt>absent</tt>: # * The managed software packages are being uninstalled. # * Any traces of the packages will be purged as good as possible. This may # include existing configuration files. The exact behavior is provider # dependent. Q.v.: # * Puppet type reference: {package, "purgeable"}[http://j.mp/xbxmNP] # * {Puppet's package provider source code}[http://j.mp/wtVCaL] # * System modifications (if any) will be reverted as good as possible # (e.g. removal of created users, services, changed log settings, ...). # * This is thus destructive and should be used with care. # Defaults to <tt>present</tt>. # # [*status*] # String to define the status of the service. Possible values: # * <tt>enabled</tt>: Service is running and will be started at boot time. # * <tt>disabled</tt>: Service is stopped and will not be started at boot # time. # * <tt>running</tt>: Service is running but will not be started at boot time. # You can use this to start a service on the first Puppet run instead of # the system startup. # * <tt>unmanaged</tt>: Service will not be started at boot time and Puppet # does not care whether the service is running or not. For example, this may # be useful if a cluster management software is used to decide when to start # the service plus assuring it is running on the desired node. # Defaults to <tt>enabled</tt>. The singular form ("service") is used for the # sake of convenience. Of course, the defined status affects all services if # more than one is managed (see <tt>service.pp</tt> to check if this is the # case). # # [*init_defaults*] # Defaults file content in hash representation # # [*init_defaults_file*] # Defaults file as puppet resource # # [*init_template*] # Service file as a template # # === Authors # # * Richard Pijnenburg <mailto:richard.pijnenburg@elasticsearch.com> # define elasticsearch::service( $ensure = $elasticsearch::ensure, $status = $elasticsearch::status, $init_defaults_file = undef, $init_defaults = undef, $init_template = undef, ) { case $elasticsearch::real_service_provider { 'init': { elasticsearch::service::init { $name: ensure => $ensure, status => $status, init_defaults_file => $init_defaults_file, init_defaults => $init_defaults, init_template => $init_template, } } 'systemd': { elasticsearch::service::systemd { $name: ensure => $ensure, status => $status, init_defaults_file => $init_defaults_file, init_defaults => $init_defaults, init_template => $init_template, } } default: { fail("Unknown service provider ${elasticsearch::real_service_provider}") } } }