[Pacemaker] Using shadow configurations noninteractively

[Phillip Frost]

On Mar 19, 2012, at 4:30 PM, Florian Haas wrote:
> On Mon, Mar 19, 2012 at 9:00 PM, Phil Frost <phil at macprofessionals.com> wrote:
>> On Mar 19, 2012, at 15:22 , Florian Haas wrote:
>>> On Mon, Mar 19, 2012 at 8:00 PM, Phil Frost <phil at macprofessionals.com> wrote:
>>>> 
>>>> Normally I'd expect some command-line option, but I can't find any. It does look like it sets the environment variable "CIB_shadow". Is that all there is to it? Is it safe to rely on that behavior?
>>> 
>>> I've never tried this specific use case, so bear with me while I go
>>> out on a limb, but the crm shell is fully scriptable. Thus you
>>> *should* be able to generate a full-blown crm script, with "cib foo"
>>> commands and whathaveyou, in a temporary file, and then just do "crm <
>>> /path/to/temp/file". Does that work for you?
>> 
>> I don't think so, because the crm shell, unlike cibadmin, has no idempotent method of configuration I've found.
> 
> Huh? What's wrong with "crm configure load replace <somefile>"?
> 
> Anyhow, I think you haven't really stated what you are trying to
> achieve, in detail. So: what is it that you want to do exactly?

Sorry, I hadn't found that command yet. "crm configure load update <file>" seems about what need. So, when I tell puppet "there's this Xen domain called foo, and it can run on xen01 or xen02", then it creates a file with a primitive and two location constraints. An example of one such file:

----------------------------8<----------------------
primitive nagios.macprofessionals.lan ocf:heartbeat:Xen \
    params \
        xmfile="/etc/xen/nagios.macprofessionals.lan.cfg" \
        name="nagios.macprofessionals.lan" \
    op start interval="0" timeout="60" \
    op stop interval="0" timeout="40" \
    op migrate_from interval="0" timeout="120" \
    op migrate_to interval="0" timeout="120" \
    op monitor interval="10" timeout="30"

location nagios.macprofessionals.lan-on-xenhost02.macprofessionals.lan nagios.macprofessionals.lan 100: xenhost02
----------------------------8<----------------------

There are several such files created in /etc/xen/crm, one for each Xen domain puppet knows about. Then, I load them with this script:

----------------------------8<----------------------
#!/bin/bash

crmdir='/etc/xen/crm'

function crm_input() {
    echo "cib delete puppet"
    echo "cib new puppet"

    for f in "$crmdir"/*.crm; do
        echo configure load update "$f"
    done
}

crm_input | crm
----------------------------8<----------------------

The end result here is to have, at any given time, a shadow configuration which represents what Puppet, based on what it already knows about the Xen domains, thinks the pacemaker configuration should be. If that differs from the live configuration, an admin receives an alert, he runs ptest and reviews it to make sure it isn't going to do anything horrible, and commits it. The higher level goal is to not be manually poking at the pacemaker configuration, because it's tedious, and people make more errors than well-written tools with this sort of task.

It seems to be working fairly well. Does this seem like a reasonable approach?