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

[Holger Teutsch]

On Mon, 2011-04-04 at 11:05 +0200, Andrew Beekhof wrote:
> On Sat, Mar 19, 2011 at 11:55 AM, Holger Teutsch <holger.teutsch at web.de> 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
> 
> Not sure this needs to be refused.

I see the problem that the node where the resource instance should be
moved off had to be specified as well to get predictable behavior. 

Consider a a 2 way clone on a 3 node cluster.
If the clone is active on A and B what should

crm_resource --move --resource myClone --node C

do ? This would require an additional --from-node or similar.

> Other than that the proposal looks sane.
> 
> My first thought was to make --move behave like --move-off if the
> resource is a clone or /ms, but since the semantics are the exact
> opposite, that might introduce introduce more problems than it solves.

That was my perception as well.

> 
> Does the original crm_resource patch implement this?

No, I will submit an updated version later this week.

- holger