$ensure => absent should handle running processes

[mjhennig]

Current Behavior:

When removing a pool or php-pool using $ensure => 'absent', during roll-out, one currently needs to handle former present ones using either manual intervention or puppet to explicitely stop the spawn-fcgi service before the pool is set to absent and, unless implicitly done already, to (re-) start it afterwards.

Expected Behavior:

Although the current behavior might be intended, users probably expect the stopping of any process associated with a pool set to absent (well, at least we/I do). Thus, the aforementioned caveat should get documented, at least.

Suggestions:

For the sake of backwards-compatibility resp. consistent behavior, there could be a (boolean) parameter that allows to enable the stopping feature. Alternatively, one could introduce an "absent-and-stopped" $ensure option that does exactly that - before being converted to "absent" internally (for /etc/spawn-fcgi/${order}-${name}).

However, I'd be willing to contribute in the implementation once there's a commitment for a suitable solution.

[LarsFronius]

Totally on your page with that. Honestly, I don't really use the module in production anymore, so from my page I am pretty much open to any implementation. That said, I expect the current behaviour to restart the service spawn-fcgi on a configuration change or setting a pool to absent, which should lead to a disappearance of the previously configured pool.

What you want is a more fine grained way of stopping a single pool?

[mjhennig]

In general, all that's missing is to ensure that the process associated with a currently present and active spawn-fcgi::pool is terminated when the pool is set to absent. Since one may consider extending the current code behind absent accordingly to result in a much too drastic change in behavior, this is probably better done with an additional parameter or ensure state. So yes, one could speak of a more fine grained way of stopping a pool.

However, this seems to be a little tricky to implement properly: Although the Puppet manifest changes are probably quite trivial, it is actually the init-script that should take over stopping the process, if any, in order to avoid code-duplication but still use e.g. start-stop-daemon and the configuration applied (via template() and /etc/default/spawn-fcgi, for example).

One suggestion would be modifying the the init-spawn-fcgi.erb script to allow for the $POOLS environment variable being set by the user, in order to recognize the following command:

# POOLS=$order-$name /etc/init.d/spawn-fcgi stop

Then one could easily patch the pool.erb manifest to accept either an additional parameter ...

spawn-fcgi::pool {$name:
    ensure => 'absent',
    /* stops the active process, only considered for 'absent' state */
    purge => true,
}

... or a third possible value for $ensure ...

spawn-fcgi::pool {$name:
    /* stops the active process, implies 'absent'  */
    ensure => 'purged',
}

... in order to include a simple exec { ... } of the aforementioned command when applicable.

Other solutions are possible as well, of course. You may want to address some improvements for the above approach? Or maybe you can suggest an alternative implementation?