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.
> >
> > 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.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
