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 _______________________________________________ Pacemaker mailing list: Pacemaker@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
