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

[Andrew Beekhof]

On Sat, Mar 19, 2011 at 11:55 AM, Holger Teutsch <holger.teutsch at web.de> wrote:
> Hi Dejan,
>
> On Fri, 2011-03-18 at 14:24 +0100, Dejan Muhamedagic wrote:
>> Hi,
>>
>> On Fri, Mar 18, 2011 at 12:21:40PM +0100, Holger Teutsch wrote:
>> > Hi,
>> > I would like to submit 2 patches of an initial implementation for
>> > discussion.
> ..
>> > To recall:
>> >
>> > crm_resource --move resource
>> > creates a "standby" rule that moves the resource off the currently
>> > active node
>> >
>> > while
>> >
>> > crm_resource --move resource --node newnode
>> > creates a "prefer" rule that moves the resource to the new node.
>> >
>> > When dealing with clones and masters the behavior was random as the code
>> > only considers the node where the first instance of the clone was
>> > started.
>> >
>> > The new code behaves consistently for the master role of an m/s
>> > resource. The options "--master" and "rsc:master" are somewhat redundant
>> > as a "slave" move is not supported. Currently it's more an
>> > acknowledgement of the user.
>> >
>> > On the other hand it is desirable (and was requested several times on
>> > the ML) to stop a single resource instance of a clone or master on a
>> > specific node.
>> >
>> > Should that be implemented by something like
>> >
>> > "crm_resource --move-off --resource myresource --node devel2" ?
>> >
>> > or should
>> >
>> > crm_resource refuse to work on clones
>> >
>> > and/or should moving the master role be the default for m/s resources
>> > and the "--master" option discarded ?
>>
>> I think that we also need to consider the case when clone-max is
>> less than the number of nodes. If I understood correctly what you
>> were saying. So, all of move slave and move master and move clone
>> should be possible.
>>
>
> I think the following use cases cover what can be done with such kind of
> interface:
>
> crm_resource --moveoff --resource myresource --node mynode
>   -> all resource variants: check whether active on mynode, then create standby constraint
>
> crm_resource --move --resource myresource
>   -> primitive/group: convert to --moveoff --node `current_node`
>   -> clone/master: refused
>
> crm_resource --move --resource myresource --node mynode
>  -> primitive/group: create prefer constraint
>  -> clone/master: refused

Not sure this needs to be refused.
Other than that the proposal looks sane.

My first thought was to make --move behave like --move-off if the
resource is a clone or /ms, but since the semantics are the exact
opposite, that might introduce introduce more problems than it solves.

Does the original crm_resource patch implement this?

>
> crm_resource --move --resource myresource --master --node mynode
>  -> master: create prefer constraint for master role
>  -> others: refused
>
> They should work (witch foreseeable outcome!) regardless of the setting of clone-max.
>
> Regards
> Holger
>
>
>> Cheers,
>>
>> Dejan
>>
>> > Regards
>> > 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
>