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

[Dejan Muhamedagic]

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
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.

Cheers,

Dejan

> Regards
> Holger
> 
> 
> > Cheers,
> > 
> > Dejan
> > 
> > > Regards
> > > Holger
> > 
> 
> 
> 
> _______________________________________________
> Pacemaker mailing list: Pacemaker at 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker