Hi Holger, On Thu, Apr 07, 2011 at 10:03:49AM +0200, Holger Teutsch wrote: > 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
All looks fine to me. > For the shell: > Should we go for similar commands or keep "migrate-XXX" migrate is a bit of a misnomer, could be confused with the migrate operation. I'd vote to leave old migrate/unmigrate as deprecated and introduce just move-from/to/cleanup variants. > 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 Well, how about remove-move? ;-) Cheers, Dejan > 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 _______________________________________________ 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