[Pacemaker] Installation woes (w/Debian packages)

[Matthew Palmer]

On Fri, Oct 16, 2009 at 09:23:41AM +0200, Colin wrote:
> On Thu, Oct 15, 2009 at 10:51 AM, Matthew Palmer <mpalmer at hezmatt.org> wrote:
> > On Thu, Oct 15, 2009 at 10:07:56AM +0200, Colin wrote:
> >> Another question regarding how to activate a pacemaker config: Is
> >> there any way to activate the config before the cluster starts up?
> >>
> >> (Scenario is that the installation of the cluster nodes is fully
> >> automatic. It seems a bit awkward how to configure pacemaker if I
> >> can't just write out a config file during install: I need to somehow
> >> make sure that on first system boot a script that activates my config
> >> is executed, but not too early because it takes a minute or so until
> >> cibadmin(1) and friends actually work...)
> >
> > I believe you can drop a cib.xml into place before the cluster first starts
> > and it'll pick up and run with that. ?I'm not a fan of that method, though,
> > as it has all the same problems as imaging machines (no easy means of
> > updating running configs the same way as you update "initial" configs, and
> > so on). ?We're configuring pacemaker using Puppet, just describing the
> > primitives, groups, constraints and so on in the manifest and having Puppet
> > do all the heavy lifting if required.
> 
> Thanks for the note, plus: I've never heard of Puppet, but will check it out.
> 
> (1 min later: http://wiki.github.com/camptocamp/puppet-pacemaker has
> no downloads, and no documentation; is it even remotely stable/ready
> for use?)

No idea, we wrote our own pacemaker management manifests.  I've found
publically-available Puppet manifests to be uniformly poor quality,
undocumented, site-specific crap.

> > Why do you need to have the config setup completely before starting
> > the cluster, though?
> 
> Let's just say I like my programs/daemons to start up with the correct
> configuration, because I've already been burnt: Some time back there
> was a similar problem with a different application where the default
> that it started up with just didn't work correctly; it's always easier
> when a program/daemon just reads a config file, and monitors it for
> changes (or re-reads it on HUP), these application-specific ways of
> feeding a config into an already running program are particular
> annoying because every program uses a different method for it.

If this were a single-machine service, I'd completely agree with you. 
Unfortunately, a cluster service like pacemaker needs to have absolutely
consistent configuration across all the nodes in the cluster, and having it
read off a file on disk would make that *amazingly* difficult and dangerous. 
I remember the fun and games I had dealing with cman (or whatever it was
that went with that) and it's "read an XML config file and update everyone"
model.  I'll take "crm configure edit" over that any day, TYVM.

- Matt