The bug is in the function is_normal_node.
This function checks the attribute "type" for state "normal".
But this attribute is not used any more.
 
CIB output from Pacemaker 1.1.8
    <nodes>
      <node id="int2node1" uname="int2node1">
        <instance_attributes id="nodes-int2node1">
          <nvpair id="nodes-int2node1-standby" name="standby" value="off"/>
      </node>
      <node id="int2node2" uname="int2node2">
        <instance_attributes id="nodes-int2node2">
          <nvpair id="nodes-int2node2-standby" name="standby" value="on"/>
      </node>
    </nodes>

CIB output from Pacemaker 1.1.7
    <nodes>
      <node id="int1node1" type="normal" uname="int1node1">
      </node>
      <node id="int1node2" type="normal" uname="int1node2">
      </node>
    </nodes>
 
Therefore, function listnodes will not return any node and function standby will use the current node as node and the first argument as lifetime.
In case of specified both (node and lifetime) it works because of other else path.
Rainer
 
Gesendet: Mittwoch, 15. Mai 2013 um 21:31 Uhr
Von: "Lars Ellenberg" <lars.ellenb...@linbit.com>
An: pacemaker@oss.clusterlabs.org
Betreff: Re: [Pacemaker] crm subshell 1.2.4 incompatible to pacemaker 1.1.9?
On Wed, May 15, 2013 at 03:34:14PM +0200, Dejan Muhamedagic wrote:
> On Tue, May 14, 2013 at 10:03:59PM +0200, Lars Ellenberg wrote:
> > On Tue, May 14, 2013 at 09:59:50PM +0200, Lars Ellenberg wrote:
> > > On Mon, May 13, 2013 at 01:53:11PM +0200, Michael Schwartzkopff wrote:
> > > > Hi,
> > > >
> > > > crm tells me it is version 1.2.4
> > > > pacemaker tell me it is verison 1.1.9
> > > >
> > > > So it should work since incompatibilities are resolved in crm higher that
> > > > version 1.2.1. Anywas crm tells me nonsense:
> > > >
> > > > # crm
> > > > crm(live)# node
> > > > crm(live)node# standby node1
> > > > ERROR: bad lifetime: node1
> > >
> > > Your node is not named node1.
> > > check: crm node list
> > >
> > > Maybe a typo, maybe some case-is-significant nonsense,
> > > maybe you just forgot to use the fqdn.
> > > maybe the check for "is this a known node name" is (now) broken?
> > >
> > >
> > > standby with just one argument checks if that argument
> > > happens to be a known node name,
> > > and assumes that if it is not,
> > > it "has to be" a lifetime,
> > > and the current node is used as node name...
> > >
> > > Maybe we should invert that logic, and instead compare the single
> > > argument against allowed lifetime values (reboot, forever), and assume
> > > it is supposed to be a node name otherwise?
> > >
> > > Then the error would become
> > > ERROR: unknown node name: node1
> > >
> > > Which is probably more useful most of the time.
> > >
> > > Dejan?
> >
> > Something like this maybe:
> >
> > diff --git a/modules/ui.py.in b/modules/ui.py.in
> > --- a/modules/ui.py.in
> > +++ b/modules/ui.py.in
> > @@ -1185,7 +1185,7 @@ class NodeMgmt(UserInterface):
> > if not args:
> > node = vars.this_node
> > if len(args) == 1:
> > - if not args[0] in listnodes():
> > + if args[0] in ("reboot", "forever"):
>
> Yes, I wanted to look at it again. Another complication is that
> the lifetime can be just about anything in that date ISO format.

That may well be, but right now those would be rejected by crmsh
anyways:

if lifetime not in (None,"reboot","forever"):
common_err("bad lifetime: %s" % lifetime)
return False

--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

_______________________________________________
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

Reply via email to