Everything is a Freaking DNS problem

I got around this issue by creating classes in my pacemaker module, which take care of disabling given services at boot time.

The general case (ensure=>running) is defined in the service's module (for instance the apache module), because we reasonably almost always want services to be started at boot time and be running by default. When a special need arises (such as services managed by pacemaker), the problem belongs to whatever component triggered it (namely pacemaker) and has to be handled there.

This basically boils down to:

class pacemaker::apache inherits apache {
  Service["apache"] {
    ensure => undef,
    enable => false,
  }
}

As a side note, for the specific case of pacemaker, in some cases, you can use the clone resource, which allows 2 instances of the same primitive to run simultaneously on 2 different nodes. For a webserver for example, it probably doesn't matter if it is also running on your failover node. For a R/W database, it may not be possible, of course...

primitive svc_apache ocf:heartbeat:apache ...
clone clone_apache svc_apache meta clone-max=2 clone-node-max=1

Cheers,
Marc

PS: thanks for the lift to the airport last week-end ;-)

Despite not being fully consistent across modules, the example42 folks have a rather good set of guidelines in how they structure their modules that solve this problem. Namely each module should implement the following subclasses:
* ::install
* ::config
* ::enable
* ::disableboot

This seems to be good practice in general and I'm trying to standardize on it.

Maybe i'm not as experienced with 'clustered' software, but everything we run in our shop comes up running on bootup. So from that perspective, i disagree. We cluster and scale by not using any resource management framework.

Now Al's on to something by having a disabled subclass for everything. Still, it's a real mess to have to implement this all by hand, it's really just busy work for the module devs.

What you really want is a system that delivers the configs and 'just works' for the small scale. When you need to introduce something larger scale, you can use something to apply triggers and take one time actions on said servers. We have to look into it ourselves, but i think you want something like mcollective.

Above all, you don't want to break the workflow for newcomers. It should still just work.

Yes, you're completely right. I'm doing like Al since I started configuring clusters with puppet :)

Nice point, and actually I've faced similar situations.
In my modules if you include the base class (include apache) you enable the service, but I alwyas provide also two subclasses:
apache::disable (ensure => stopped, enable => false)
apache::disableboot (enable => false)
This second case is typical for clusters where you don't want to manage the running status of the service and don' want to start it at boot (the cluster does it).
Maybe it's not the best naming convention even, but does what we need.

cu
Al