On Jan 28, 3:44 am, Matt <mattmora...@gmail.com> wrote:
> I'm wondering if anyone has any best practice when needing to do a service
> stop, and exec, and then a service start in a sequential order. Up until
> now notifying a service has been fine, but i've now come across an issue
> where I need to make sure a service is stoppped, so something then start it
> again.
>
> Before I get into manifest hell, i'm wondering if there is an obvious way to
> do it.
In short, no, there is no obvious or easy way to do it.
In long: Puppet is not a script engine, and its language is not a
scripting language. You *can* write scripts in Puppet, but it is
cumbersome. Puppet is all about achieving and maintaining particular
states of system resources, intentionally de-emphasizing the mechanism
for getting from here to there. Thus, "how do I make Puppet perform
<some sequence of actions>?" is rarely a useful question. Puppet does
have have "require" and "before" metaparameters, however, with which
you can express resource dependencies; these constrain the order in
which resources are applied.
More specific to your situation, each Service resource will ensure
exactly one state of the service it manages, so you cannot use a
Service to both stop and start a service in the same Puppet run. You
can, however, make a Service *restart* its managed service by having
it subscribe to another resource or having another resource notify
it. If it would work for you to <do something> then restart the
service, then that fits better with Puppet. Example:
class my_service {
file { "/etc/my_service/my_service.conf":
source => "...",
# ...
}
service { "my_service":
subscribe => File["/etc/my_service/my_service.conf"], # (or
use a notify => in the File resource)
ensure => "running",
# ...
}
}
On the other hand, if your <do something> absolutely requires the
service to be already stopped, then you can incorporate service
stoppage into it, and use a Service to ensure it is later started. In
this case, you do lose the abstraction provided by Service, making
your manifest system-dependent:
class my_service2 {
exec { "update_my_service2":
command => "/bin/sh -c '/sbin/service my_service2 stop && /usr/
bin/do_something'",
notify => Service["my_service2"],
}
service {"my_service2":
ensure => "running",
# ...
}
}
On the third hand, if you need a service to perform some action in the
middle of every restart, then you probably need to create a custom
Service subclass and a suitable Provider for it. An example would be
well beyond the scope of this thread, but extending Puppet is
comparatively easy and very powerful. Remember, though, with great
power comes great responsibility....
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-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
