Ensure Running

Has anyone noticed that pretty much every puppet module one finds on the internet by default enables the service they try to configure in the module

When looking at it from a single machine point of view it makes sense to include the module , have it configure your service and directly enable it by default.

So I started wondering .. isn't there anybody out there who is building clusters ? Where services have to configured on multiple nodes but should NOT be running acitvely on all nodes by default because there is an external tool which manages that for you (Pacemaker framework eg.)

Agreed it's a small patch to get the functionality you want , but it brings an extra overhead when one upgrades the modules etc.

So if it doesn't bother you please split your puppet module in 2 parts.. one you call to configure the service, another which you call to enable the service , if you want to.

thnx !

Comments

Marc Fournier's picture

#1 Marc Fournier : I put ensure=>undef in the cluster management module

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:

  1. class pacemaker::apache inherits apache {
  2. Service["apache"] {
  3. ensure => undef,
  4. enable => false,
  5. }
  6. }

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...

  1. primitive svc_apache ocf:heartbeat:apache ...
  2. 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 ;-)


Spike's picture

#2 Spike : Inspired by example42 module guidelines

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.


loupgaroublond's picture

#3 loupgaroublond : Maybe i'm not as experienced

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.


Al's picture

#4 Al : Modules templating is the (my) solution

loupgaroublond, actually all the (newer) modules I do are based on a template called foo, so for me creating a full featured module with all the frills I want is , often, just a matter of running a script and changing only the params.pp class. Actually generally various other modifications are needed to comply to specific applications, but all these disable, absent, disableboot (but also debug, monitor, backup, firewall and so on) subclasses come out automatically and I hardly touch them in a newly generated module.

Using qualified variables ($modulename::params::variable) and a params.pp class (or whatever name you might give to it) is the key to modules' standardization and quick cloning (kudos to Dan Bode for having convinced me about the usefulness of a params.pp class).

Regards,
Al


masterzen's picture

#5 masterzen : Yes, you're completely right.

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


Al's picture

#6 Al : Agree

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


Kris Buytaert's picture

#7 Kris Buytaert : overlooked

Hmm... that is farily well hidden in a separate file :)
I hadn't even noticed till you mentionned it that there is a separate disable.pp in some of your modules.

As for naming , dare i suggest "unmanaged" .. as the service probably should be enabled, just not by puppet ..