[Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional "role" parameter

Holger Teutsch holger.teutsch at web.de
Mon Mar 21 16:45:55 EDT 2011


Hi Dejan,

On Mon, 2011-03-21 at 16:11 +0100, Dejan Muhamedagic wrote:
> Hi Holger,
> 
> On Sat, Mar 19, 2011 at 11:55:57AM +0100, Holger Teutsch wrote:
> > Hi Dejan,
> > 
> > On Fri, 2011-03-18 at 14:24 +0100, Dejan Muhamedagic wrote:
> > > Hi,
> > > 
> > > On Fri, Mar 18, 2011 at 12:21:40PM +0100, Holger Teutsch wrote:
> > > > Hi,
> > > > I would like to submit 2 patches of an initial implementation for
> > > > discussion.
> > ..
> > > > To recall:
> > > > 
> > > > crm_resource --move resource
> > > > creates a "standby" rule that moves the resource off the currently
> > > > active node
> > > > 
> > > > while
> > > > 
> > > > crm_resource --move resource --node newnode
> > > > creates a "prefer" rule that moves the resource to the new node.
> > > > 
> > > > When dealing with clones and masters the behavior was random as the code
> > > > only considers the node where the first instance of the clone was
> > > > started.
> > > > 
> > > > The new code behaves consistently for the master role of an m/s
> > > > resource. The options "--master" and "rsc:master" are somewhat redundant
> > > > as a "slave" move is not supported. Currently it's more an
> > > > acknowledgement of the user.
> > > > 
> > > > On the other hand it is desirable (and was requested several times on
> > > > the ML) to stop a single resource instance of a clone or master on a
> > > > specific node.
> > > > 
> > > > Should that be implemented by something like
> > > >  
> > > > "crm_resource --move-off --resource myresource --node devel2" ?
> > > > 
> > > > or should
> > > > 
> > > > crm_resource refuse to work on clones
> > > > 
> > > > and/or should moving the master role be the default for m/s resources
> > > > and the "--master" option discarded ?
> > > 
> > > I think that we also need to consider the case when clone-max is
> > > less than the number of nodes. If I understood correctly what you
> > > were saying. So, all of move slave and move master and move clone
> > > should be possible.
> > > 
> > 
> > I think the following use cases cover what can be done with such kind of
> > interface:
> > 
> > crm_resource --moveoff --resource myresource --node mynode
> >    -> all resource variants: check whether active on mynode, then create standby constraint
> > 
> > crm_resource --move --resource myresource
> >    -> primitive/group: convert to --moveoff --node `current_node`
> >    -> clone/master: refused
> > 
> > crm_resource --move --resource myresource --node mynode
> >   -> primitive/group: create prefer constraint
> >   -> clone/master: refused
> > 
> > crm_resource --move --resource myresource --master --node mynode
> >   -> master: create prefer constraint for master role
> >   -> others: refused
> > 
> > They should work (witch foreseeable outcome!) regardless of the setting of clone-max.
> 
> This seems quite complicated to me. Took me a while to figure
> out what's what and where :) Why bother doing the thinking for

I'm afraid the matter *is* complicated. The current implementation of 

crm_resource --move --resource myResource

(without node name) is moving off the resource from the node it is
currently active on by creating a standby constraint. For clones and
masters there is no such *single* active node the constraint can be
constructed for.

Consider this use case:
I have 2 nodes and a clone or master and would like to safely get rid of
one instance on a particular node (e.g. with agents 1.0.5 the slave of a
DB2 HADR pair 8-) ). No idea how that should be done without a move-off
functionality. 

> users? The only case which seems to me worth considering is
> refusing setting role for non-ms resources. Otherwise, let's let
> the user move things around and enjoy the consequences.

Definitely not true for production clusters. The tools should produce
least surprise consequences.
  
> 
> Cheers,
> 

Over the weekend I implemented the above mentioned functionality. Drop
me note if you want to play with an early snapshot 8-)

Regards
Holger 





More information about the Pacemaker mailing list