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

[Holger Teutsch]

Hi Dejan,

On Tue, 2011-04-05 at 13:40 +0200, Dejan Muhamedagic wrote:
> Hi Holger,
> 
> On Tue, Apr 05, 2011 at 01:19:56PM +0200, Holger Teutsch wrote:
> > Hi Dejan,
> > 
> > On Tue, 2011-04-05 at 12:27 +0200, Dejan Muhamedagic wrote:
> > > On Tue, Apr 05, 2011 at 12:10:48PM +0200, Holger Teutsch wrote:
> > > > Hi Dejan,
> > > > 
> > > > On Tue, 2011-04-05 at 11:48 +0200, Dejan Muhamedagic wrote:
> > > > > Hi Holger,
> > > > > 
> > > > > On Mon, Apr 04, 2011 at 09:31:02PM +0200, Holger Teutsch wrote:
> > > > > > On Mon, 2011-04-04 at 15:24 +0200, Andrew Beekhof wrote:
> > > > > [...]
> > > > > > 
> > > > > > crm_resource --move-off --resource myClone --node C
> > > > > >    -> I want the instance moved off C, regardless where it is moved on
> > > > > 
> > > > > What is the difference between move-off and unmigrate (-U)?
> > > > 
> > > > --move-off -> create a constraint that a resource should *not* run on
> > > > the specific node (partly as before --move without --node)
> > > > 
> > > > -U: zap all migration constraints (as before) 
> > > 
> > > Ah, right, sorry, wanted to ask about the difference between
> > > move-off and move. The description looks the same as for move. Is
> > > it that in this case it is for clones so crm_resource needs an
> > > extra node parameter? You wrote in the doc:
> > > 
> > > 	+Migrate a resource (-instance for clones/masters) off the specified node.
> > > 
> > > The '-instance' looks somewhat funny. Why not say "Move/migrate a
> > > clone or master/slave instance away from the specified node"?
> > 
> > Moving away works for all kinds of resources so the text now looks like:
> > 
> > diff -r b4f456380f60 doc/crm_cli.txt
> > --- a/doc/crm_cli.txt	Thu Mar 17 09:41:25 2011 +0100
> > +++ b/doc/crm_cli.txt	Tue Apr 05 13:08:10 2011 +0200
> > @@ -818,10 +818,25 @@
> >  running on the current node. Additionally, you may specify a
> >  lifetime for the constraint---once it expires, the location
> >  constraint will no longer be active.
> > +For a master resource specify <rsc>:master to move the master role.
> >  
> >  Usage:
> >  ...............
> > -        migrate <rsc> [<node>] [<lifetime>] [force]
> > +        migrate <rsc>[:master] [<node>] [<lifetime>] [force]
> > +...............
> > +
> > +[[cmdhelp_resource_migrateoff,migrate a resource off the specified
> > node]]
> > +==== `migrateoff` (`moveoff`)
> > +
> > +Migrate a resource away from the specified node. 
> > +The resource is migrated by creating a constraint which prevents it
> > from
> > +running on the specified node. Additionally, you may specify a
> > +lifetime for the constraint---once it expires, the location
> > +constraint will no longer be active.
> > +
> > +Usage:
> > +...............
> > +        migrateoff <rsc> <node> [<lifetime>] [force]
> >  ...............
> >  
> >  [[cmdhelp_resource_unmigrate,unmigrate a resource to another node]]
> > 
> > > 
> > > I must say that I still find all this quite confusing, i.e. now
> > > we have "move", "unmove", and "move-off", but it's probably just me :)
> > 
> > Think of "move" == "move-to" then it is simpler 8-)
> > 
> > ... keeping in mind that for backward compatibility
> > 
> > crm_resource --move --resource myResource
> > 
> > is equivalent
> > 
> > crm_resource --move-off --resource myResource --node $(current node)
> > 
> > But as there is no "current node" for clones / masters the old
> > implementation did some random movements...
> 
> OK. Thanks for the clarification. I'd like to revise my previous
> comment about restricting use of certain constructs. For
> instance, in this case, if the command would result in a random
> movement then the shell should at least issue a warning about it.
> Or perhaps refuse to do that completely. I didn't take a look yet
> at the code, perhaps you've already done that.
> 
> Thanks,
> 
> Dejan
> 
> 

I admit you have to specify more verbosely what you want to achieve but
then the patched versions (based on patches I submitted today around
10:01) execute consistent and without surprises - at least for my test
cases. 

Regards
Holger