Controlling the order of stop/starts on refresh between dependent services.

[Paul Gale]

Hi,

Using Puppet v2.7.25.

I have two services that have a refresh dependency between them, namely: Service['foo'] ~> Service['bar']

This equates to: stop/start 'foo' then stop/start 'bar', whenever 'foo' is refreshed.

Ideally I'd like the underlying series of operations to be: stop 'bar', stop/start 'foo', start 'bar'.

How can I do this without resorting to using execs?

If bar were to be running whilst foo was unavailable (even if for a moment) bad things would happen. To make matters worse (or more interesting) each service is managed by a separate module.  

Thanks,
Paul

[jcbollinger]

On Monday, June 2, 2014 5:04:55 PM UTC-5, Paul Gale wrote:

Hi,

Using Puppet v2.7.25.

I have two services that have a refresh dependency between them, namely: Service['foo'] ~> Service['bar']

This equates to: stop/start 'foo' then stop/start 'bar', whenever 'foo' is refreshed.

Ideally I'd like the underlying series of operations to be: stop 'bar', stop/start 'foo', start 'bar'.

How can I do this without resorting to using execs?

You need at least one Exec to do that without adding custom components to Puppet or modifying the services (at least their initscript equivalents).  That could look like so:

service { 'foo':
  ensure => 'running'
}

service { 'bar':
  ensure => 'running'
}

nested_service { 'foo':
  outer => 'bar',
  inner => 'foo'
}

define nested_services($outer, $inner) {
  exec { "stop $outer":
    command => "/sbin/service $outer stop",
    refreshonly => true
  }
  ~> Service['$inner]
  ~> Service[$outer]
}

Even then, you must direct refresh events at the Nested_services resource instead of directly at Service['foo'].
 

If bar were to be running whilst foo was unavailable (even if for a moment) bad things would happen. To make matters worse (or more interesting) each service is managed by a separate module.  

In that case, I would consider modifying Service['foo']'s initscript equivalent, notwithstanding anything you do in Puppet.   Alternatively, if the only reason service foo needs to run in this context is to provide services for bar, then you could consider wrapping the pair in a separate initscript to treat them jointly as a single service.  That would have the added advantage that your constraint that bar not run without foo can be enforced for all avenues of service management, including command line.


John