On Wed, Mar 21, 2012 at 12:21:55PM -0400, Phillip Frost wrote:
> 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?
Yes.
I guess that the answer to your question is "crm cib commit <shadow>".
Thanks,
Dejan
> _______________________________________________
> 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
_______________________________________________
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
