Mailing List Archive

order directives and pacemaker update
Since I applied the most recent Pacemaker update last Friday (now
running pacemaker-1.0.8-2.el5.x86_64 on CentOS 5), I can no longer
enter order directives. I am using the exact same syntax that I used
previously, and the syntax matches some existing directives, but the crm
shell won't take it. Here is an example:

crm(live)configure# primitive VM-cfvmserve ocf:heartbeat:Xen params
xmfile="/etc/xen/cfvmserve" op monitor interval="10" timeout="120"
depth="0" op start interval="0" timeout="60s" op stop interval="0"
timeout="120s" meta allow-migrate="true" target-role="Stopped"
crm(live)configure# order vmnfs-before-cfvmserve inf: vmnfs-cl
VM-cfvmserve
crm(live)configure# verify
ERROR: cib-bootstrap-options: attribute dc-version does not exist
ERROR: cib-bootstrap-options: attribute cluster-infrastructure does not
exist
ERROR: cib-bootstrap-options: attribute last-lrm-refresh does not exist

I don't know why I am getting these errors and I am not sure they are
relevant to the problem I am seeing. But here's what happens later:

crm(live)configure# commit
element rsc_order: validity error : IDREF attribute first references an
unknown ID "vmnfs-cl"

"vmnfs-cl" is a clone resource of a file system mount. That resource is,
and always has been, present. I also have a number of order directives
that reference it that are already in the CIB and are working. Here's a
snippet from "crm configure show":

primitive vmnfs ocf:heartbeat:Filesystem \
params directory="/vmnfs" device="phantom.ucar.edu:/vol/dsgtest"
fstype="nfs" \
op start interval="0" timeout="60s" \
op stop interval="0" timeout="60s"
....
clone vmnfs-cl vmnfs \
meta target-role="Started"
....
order vmnfs-before-linstall inf: vmnfs-cl VM-linstall

(this last is an example of one that is already present that works).

Lastly, another part of the configure show output addressing the ERROR
messages above:

property $id="cib-bootstrap-options" \
dc-version="1.0.8-3225fc0d98c8fcd0f7b24f0134e89967136a9b00" \
cluster-infrastructure="Heartbeat" \
stonith-enabled="true" \
last-lrm-refresh="1270484103" \
default-resource-stickiness=""

This is currently preventing me from being able to add any more virtual
machines. The ones that are already in are working (including proper
failovers and migration). So is this a bug in the new code or is it
something I was doing wrong that is now being flagged that I just
luckily got by with before?

I can send the full configuration if that is deemed necessary but I
would have to sanitize it to remove idrac passwords, local IP addresses,
and so forth, so I won't do that unless it's the only way to figure this
out.

--Greg




_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
Re: order directives and pacemaker update [ In reply to ]
Hi,

On Mon, Apr 05, 2010 at 10:49:25AM -0600, Greg Woods wrote:
> Since I applied the most recent Pacemaker update last Friday (now
> running pacemaker-1.0.8-2.el5.x86_64 on CentOS 5), I can no longer
> enter order directives. I am using the exact same syntax that I used
> previously, and the syntax matches some existing directives, but the crm
> shell won't take it. Here is an example:
>
> crm(live)configure# primitive VM-cfvmserve ocf:heartbeat:Xen params
> xmfile="/etc/xen/cfvmserve" op monitor interval="10" timeout="120"
> depth="0" op start interval="0" timeout="60s" op stop interval="0"
> timeout="120s" meta allow-migrate="true" target-role="Stopped"
> crm(live)configure# order vmnfs-before-cfvmserve inf: vmnfs-cl
> VM-cfvmserve
> crm(live)configure# verify
> ERROR: cib-bootstrap-options: attribute dc-version does not exist
> ERROR: cib-bootstrap-options: attribute cluster-infrastructure does not
> exist
> ERROR: cib-bootstrap-options: attribute last-lrm-refresh does not exist
>
> I don't know why I am getting these errors and I am not sure they are
> relevant to the problem I am seeing.

They are not. You can ignore them.

> But here's what happens later:
>
> crm(live)configure# commit
> element rsc_order: validity error : IDREF attribute first references an
> unknown ID "vmnfs-cl"
>
> "vmnfs-cl" is a clone resource of a file system mount. That resource is,
> and always has been, present. I also have a number of order directives
> that reference it that are already in the CIB and are working. Here's a
> snippet from "crm configure show":
>
> primitive vmnfs ocf:heartbeat:Filesystem \
> params directory="/vmnfs" device="phantom.ucar.edu:/vol/dsgtest"
> fstype="nfs" \
> op start interval="0" timeout="60s" \
> op stop interval="0" timeout="60s"
> ....
> clone vmnfs-cl vmnfs \
> meta target-role="Started"
> ....
> order vmnfs-before-linstall inf: vmnfs-cl VM-linstall
>
> (this last is an example of one that is already present that works).
>
> Lastly, another part of the configure show output addressing the ERROR
> messages above:
>
> property $id="cib-bootstrap-options" \
> dc-version="1.0.8-3225fc0d98c8fcd0f7b24f0134e89967136a9b00" \
> cluster-infrastructure="Heartbeat" \
> stonith-enabled="true" \
> last-lrm-refresh="1270484103" \
> default-resource-stickiness=""
>
> This is currently preventing me from being able to add any more virtual
> machines. The ones that are already in are working (including proper
> failovers and migration). So is this a bug in the new code or is it
> something I was doing wrong that is now being flagged that I just
> luckily got by with before?

There's a crm shell bug in 1.0.8-2 in the validation process.
Either revert to the earlier pacemaker or apply this patch:

http://hg.clusterlabs.org/pacemaker/stable-1.0/rev/422fed9d8776

(that's python so you can apply the patch to the code which
resides in /usr/lib*/python2*/site-packages/crm).

For the attribute problems, there are also:

http://hg.clusterlabs.org/pacemaker/stable-1.0/rev/042548a451fc
http://hg.clusterlabs.org/pacemaker/stable-1.0/rev/23a208d53fd2

Thanks,

Dejan

> I can send the full configuration if that is deemed necessary but I
> would have to sanitize it to remove idrac passwords, local IP addresses,
> and so forth, so I won't do that unless it's the only way to figure this
> out.
>
> --Greg
>
>
>
>
> _______________________________________________
> Linux-HA mailing list
> Linux-HA@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
Re: order directives and pacemaker update [ In reply to ]
On Tue, 2010-04-06 at 12:29 +0200, Dejan Muhamedagic wrote:

>
> There's a crm shell bug in 1.0.8-2 in the validation process.
> Either revert to the earlier pacemaker or apply this patch:
>
> http://hg.clusterlabs.org/pacemaker/stable-1.0/rev/422fed9d8776

OK, that's a relief. I chose to apply the patch because there are some
features of 1.0.8-2 that I like (such as warning me when I have
forgotten to explicitly set the start/stop timeouts). But after applying
the patch, and figuring out how to compile Python into bytecode, it now
works! Thank you very much. Presumably the next released version will
have this patch in it so this is a one-time thing.

--Greg


_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
Re: order directives and pacemaker update [ In reply to ]
Hi,

On Tue, Apr 06, 2010 at 10:24:53AM -0600, Greg Woods wrote:
> On Tue, 2010-04-06 at 12:29 +0200, Dejan Muhamedagic wrote:
>
> >
> > There's a crm shell bug in 1.0.8-2 in the validation process.
> > Either revert to the earlier pacemaker or apply this patch:
> >
> > http://hg.clusterlabs.org/pacemaker/stable-1.0/rev/422fed9d8776
>
> OK, that's a relief. I chose to apply the patch because there are some
> features of 1.0.8-2 that I like (such as warning me when I have
> forgotten to explicitly set the start/stop timeouts). But after applying
> the patch, and figuring out how to compile Python into bytecode, it now

I have here bytecode automatically compiled if the code file
is newer.

> works! Thank you very much. Presumably the next released version will
> have this patch in it so this is a one-time thing.

Of course.

Thanks,

Dejan

>
> --Greg
>
>
> _______________________________________________
> Linux-HA mailing list
> Linux-HA@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems