override/replace native types

[Guillaume Rousse]

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

[Craig Dunn]

> 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

[Guillaume Rousse]

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

[jcbollinger]

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

[Guillaume Rousse]

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