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

Tue Apr 5 04:01:43 EDT 2011

On Mon, 2011-04-04 at 21:31 +0200, Holger Teutsch wrote:
> On Mon, 2011-04-04 at 15:24 +0200, Andrew Beekhof wrote:
> > On Mon, Apr 4, 2011 at 2:43 PM, Holger Teutsch <holger.teutsch at web.de> wrote:
> > > 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 ?
> > 
> > I would expect it to create the +inf constraint for C but no
> > contraint(s) for the current location(s)
> 
> You are right. These are different and valid use cases.
> 
> crm_resource --move --resource myClone --node C
>    -> I want an instance on C, regardless where it is moved off
> 
> crm_resource --move-off --resource myClone --node C
>    -> I want the instance moved off C, regardless where it is moved on
> 
> I tried them out with a reimplementation of the patch on a 3 node
> cluster with a resource with clone-max=2. The behavior appears logical
> (at least to me 8-) ).
> 
> > 
> > > 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

Hi,
I submit revised patches for review.
Summarizing preceding discussions the following functionality is
implemented:

crm_resource --move-off --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 --move-off --node `current_node`
   -> clone/master: refused

crm_resource --move --resource myresource --node mynode
  -> all resource variants: create prefer constraint

crm_resource --move --resource myresource --master --node mynode
  -> master: check whether active as slave on mynode, then create prefer constraint for master role
  -> others: refused

The patch shell_migrate.diff supports this in the shell. This stuff is
agnostic of what crm_migrate really does.

Regards
Holger

-------------- next part --------------
A non-text attachment was scrubbed...
Name: shell_migrate.diff
Type: text/x-patch
Size: 3948 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20110405/3352d29f/attachment-0006.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crm_resource.diff
Type: text/x-patch
Size: 11894 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20110405/3352d29f/attachment-0007.bin>