On Thu, 2011-04-07 at 08:57 +0200, Andrew Beekhof wrote: > On Wed, Apr 6, 2011 at 5:48 PM, Holger Teutsch <holger.teut...@web.de> wrote: > > On Wed, 2011-04-06 at 15:38 +0200, Dejan Muhamedagic wrote: > >> On Wed, Apr 06, 2011 at 01:00:36PM +0200, Andrew Beekhof wrote: > >> > On Tue, Apr 5, 2011 at 12:27 PM, Dejan Muhamedagic <deja...@fastmail.fm> > >> > wrote: > >> > > 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"? > >> > > > >> > > 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 :) > >> > > >> > Not just you. The problem is that we didn't fully understand all the > >> > use case permutations at the time. > >> > > >> > I think, not withstanding legacy computability, "move" should probably > >> > be renamed to "move-to" and this new option be called "move-from". > >> > That seems more obvious and syntactically consistent with the rest of > >> > the system. > >> > >> Yes, move-to and move-from seem more consistent than other > >> options. The problem is that the old "move" is at times one and > >> then at times another. > >> > >> > In the absence of a host name, each uses the current location for the > >> > named group/primitive resource and complains for clones. > >> > > >> > The biggest question in my mind is what to call "unmove"... > >> > "move-cleanup" perhaps? > >> > >> move-remove? :D > >> Actually, though the word is a bit awkward, unmove sounds fine > >> to me. > > > > I would vote for "move-cleanup". It's consistent to move-XXX and to my > > (german) ears "unmove" seems to stand for the previous "move" being > > undone and the stuff comes back. > > > > BTW: Has someone already tried out the code or do you trust me 8-D ? > > I trust no-one - which is why we have regression tests :-) > > > > > Stay tuned for updated patches...
Now, after an additional discussion round I propose the following: Please note that for consistency the "--node" argument is optional for "--move-from" New syntax: ----------- crm_resource --move-from --resource myresource --node mynode -> all resource variants: check whether active on mynode, then create standby constraint crm_resource --move-from --resource myresource -> primitive/group: set --node `current_node`, then create standby constraint -> clone/master: refused crm_resource --move-to --resource myresource --node mynode -> all resource variants: create prefer constraint crm_resource --move-to --resource myresource --master --node mynode -> master: check whether active as slave on mynode, then create prefer constraint for master role -> others: refused crm_resource --move-cleanup --resource myresource -> zap constraints As we are already short on meaningful single letter options I vote for long options only. Backwards Compatibility: ------------------------ crm_resource {-M|--move} --resource myresource -> output deprecation warning -> treat as crm_resource --move-from --resource myresource crm_resource {-M|--move} --resource myresource --node mynode -> output deprecation warning -> treat as crm_resource --move-to --resource myresource --node mynode crm_resource {-U|--unmove} --resource myresource -> output deprecation warning -> treat as crm_resource --move-cleanup --resource myresource For the shell: Should we go for similar commands or keep "migrate-XXX" Coming back to Dejan's proposal of "move-remove": That can be implemented of reexecuting the last move (a remove). Reimplemeting "unmove" as undo of the last move you have shortcuts for your favorite move operation move move-unmove -> back move-remove -> and forth Just kidding... > > > > - 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