On Mar 19, 2012, at 4:30 PM, Florian Haas wrote:
> On Mon, Mar 19, 2012 at 9:00 PM, Phil Frost <p...@macprofessionals.com> wrote:
>> On Mar 19, 2012, at 15:22 , Florian Haas wrote:
>>> On Mon, Mar 19, 2012 at 8:00 PM, Phil Frost <p...@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?
_______________________________________________
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org
