On Sun, Jan 31, 2010 at 7:11 AM, Matt <mattmora...@gmail.com> wrote:
> On 28 January 2010 14:22, jcbollinger <john.bollin...@stjude.org> wrote:
>
>>
>>
>> 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.
>> >
>>
>
You can override the restart functionality for a service as follows:
Ex:
#script.sh
service SERVICE stop
echo "do some other stuff"
service SERVICE start
#put the script on the machine
file{'/tmp/script.sh'
source => '/etc/puppet/files/script.sh',
}
#now specify that when the service needs to restart, it should call that
script
service{'SERVICE'
restart => '/tmp/script.sh',
require => File['/tmp/script.sh'],
}
now every refreshed that is triggered (via subscribe/notify) will run this
custom script as the restart script.
-Dan
> > 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<puppet-users%2bunsubscr...@googlegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>>
> Thanks John, that all makes perfect sense. I think it'll have to be option
> two.
>
> --
> 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<puppet-users%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
--
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.
