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

[Dejan Muhamedagic]

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.teutsch at 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 <dejanmm at 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 at 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