Hello list.
I''d like to implement a basic ''onlyif'' property, as
existing in ''exec''
type, to ''service'' type. Rather than patching the original
puppet code,
I think I could use the custom type mechanism, and implement my own
''conditional_service'' type. However, in order to keep the
benefit of
existing providers, I think renaming the type isn''t the best solution.
So, would it possible to either inherit the original type definition,
and just add the new property, or distributing a modified type copy as
part of a module would also replace original type definition for this
module ?
BTW, the exact intent is to allow to test the configuration file syntax
before reloading a service, and avoid reloading it with an invalid
state. Something as:
file { "/etc/openldap/slapd.conf":
content => template("slapd.conf.erb"),
notify => Service["slapd"]
}
service { "slapd":
ensure => "running",
onlyif => "/usr/sbin/slaptest"
}
--
BOFH excuse #362:
Plasma conduit breach
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
> BTW, the exact intent is to allow to test the configuration file syntax > before reloading a service, and avoid reloading it with an invalid > state. Something as: > > file { "/etc/openldap/slapd.conf": > content => template("slapd.conf.erb"), > notify => Service["slapd"] > } > > service { "slapd": > ensure => "running", > onlyif => "/usr/sbin/slaptest" > }Personally, I think this should be taken care of in the init script. But if you really want to do it from puppet I suppose you could override the start parameter of the service type... To fail the resource if slaptest fails... service { "slapd": ensure => "running", start => "/usr/sbin/slaptest && service slapd start", } To continue silently but not start slapd.... service { "slapd": ensure => "running", start => "( /usr/sbin/slaptest && service slapd start) || /bin/true", } But, IMO, a service init script should take care of its own pre-req''s... HTH Craig -- Craig Dunn | http://www.craigdunn.org Yahoo/Skype: craigrdunn | Twitter: @crayfishX -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Le 13/04/2012 12:07, Craig Dunn a écrit :> To fail the resource if slaptest fails... > > service { "slapd": > ensure => "running", > start => "/usr/sbin/slaptest && service slapd start", > } > > To continue silently but not start slapd.... > > service { "slapd": > ensure => "running", > start => "( /usr/sbin/slaptest && service slapd start) || /bin/true", > }Good point, I didn''t understood this property could be defined as an arbitrary shell command.> But, IMO, a service init script should take care of its own pre-req''s...Well, I see at least two reasons not to do it. First, I''d actually like to make more than just ''restart only if correct'', rather something as ''if correct then reload, else notify''. In order to use arbitrary notification mechanism (nagios, in our case, with a mail fallback), I''d rather manage this out of init script. The second is to avoid interfering with something wich is part of the distribution. If I''m forking redhat iniscript, I have to follow any fix/evolution/whatever, which is painful. BTW, redhat initscript already support this kind of check, but only at start stage, meaning restart action will do ''stop, check, and refuse to start'' :( -- BOFH excuse #230: Lusers learning curve appears to be fractal -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Apr 13, 4:08 am, Guillaume Rousse <guillomovi...@gmail.com> wrote:> Hello list. > > I''d like to implement a basic ''onlyif'' property, as existing in ''exec'' > type, to ''service'' type. Rather than patching the original puppet code, > I think I could use the custom type mechanism, and implement my own > ''conditional_service'' type. However, in order to keep the benefit of > existing providers, I think renaming the type isn''t the best solution. > > So, would it possible to either inherit the original type definition, > and just add the new property, or distributing a modified type copy as > part of a module would also replace original type definition for this > module ?No. That is, you *can* subclass the built-in type and add a parameter, but you cannot expect the existing type''s providers to work with your subclass. In fact, it is likely that the new behavior you want needs to be in the provider(s) anyway.> BTW, the exact intent is to allow to test the configuration file syntax > before reloading a service, and avoid reloading it with an invalid > state. Something as: > > file { "/etc/openldap/slapd.conf": > content => template("slapd.conf.erb"), > notify => Service["slapd"] > > } > > service { "slapd": > ensure => "running", > onlyif => "/usr/sbin/slaptest"}I''m with Craig that it would be best to rely on the initscript to perform the test. Moreover, I don''t find the current behavior that bad. Is it better to continue running the service with an out-of-date configuration? Is it better to delay discovering the problem until the machine is restarted, or until you or some other admin tries to restart the service manually? If it were my server, the answers to both questions would be "no". John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Guillaume Rousse
2012-Apr-16 13:41 UTC
Re: [Puppet Users] Re: override/replace native types
Le 16/04/2012 15:02, jcbollinger a écrit :> Moreover, I don''t find the current behavior that bad. Is it better to > continue running the service with an out-of-date configuration? Is it > better to delay discovering the problem until the machine is > restarted, or until you or some other admin tries to restart the > service manually? If it were my server, the answers to both questions > would be "no".I wholefully agree. My final objective is to test, reload is everything is OK, and notifies otherwise so as to have the problem be corrected ASAP. I described only initial step to make the point easier. I don''t want to interfere with native distribution initscripts, mainly for maintenance reasons. However, using a custom wrapper could be the solution here. -- BOFH excuse #297: Too many interrupts -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.