[Pacemaker] Proper way to migrate multistate resource?

[Chet Burgess]

On Feb 8, 2012, at 15:34 , Andrew Beekhof wrote:

> On Thu, Feb 9, 2012 at 9:58 AM, Chet Burgess <cfb at liquidreality.org> wrote:
>> 
>> 
>> 
>> On Feb 7, 2012, at 4:54 , Lars Ellenberg wrote:
>> 
>>> On Mon, Feb 06, 2012 at 04:48:26PM -0800, Chet Burgess wrote:
>>>> Greetings,
>>>> 
>>>> I'm some what new to pacemaker and have been playing around with a
>>>> number of configurations in a lab. Most recently I've been testing a
>>>> multistate resource using the ofc:pacemaker:Stateful example RA.
>>>> 
>>>> While I've gotten the agent to work and notice that if I shutdown or
>>>> kill a node the resources migrate I can't seem to figure out the
>>>> proper way to migrate the resource between nodes when they are both
>>>> up.
>>>> 
>>>> For regular resources I've used "crm resource migrate <rsc>" without
>>>> issue. However when I try this with a multistate resource it doesn't
>>>> seem to work. When I run the command it just puts the slave node into
>>>> a stopped state. If I try and tell it to migrate specifically to the
>>>> slave node it claims to already be running their (which I suppose in a
>>>> sense it is).
>>> 
>>> the crm shell does not support roles for the "move" or "migrate" command
>>> (yet; maybe in newer versions. Dejan?).
>>> 
>>> What you need to do is set a location constraint on the role.
>>> * force master role off from one node:
>>> 
>>>       location you-name-it resource-id \
>>>               rule $role=Master -inf: \
>>>               #uname eq node-where-it-should-be-slave
>>> 
>>> * or force master role off from all but one node,
>>>   note the double negation in this one:
>>> 
>>>       location you-name-it resource-id \
>>>               rule $role=Master -inf: \
>>>               #uname ne node-where-it-should-be-master
>>> 
>> 
>>        OK I finally got around to testing this today. Both scenarios described above worked as described. Thank you.
>> 
>>        One minor hitch though. When I remove the constraint the resource goes back to the original (and preferred by the configuration) node. With my non-multistate resources when I remove the constraint the resource remains on the node it was moved to until it is forced to move again with another constraint (eg. what "crm resource migrate" does).
>> 
>>        I have the default resource-stickiness set to 100
> 
> Doesn't affect promotion I'm afraid.
> One could argue that it should though.
> 

At least I'm not crazy. 

So I take it that there is no way to "stick" a master role to the "last node" that was in that state? One the preferred node becoming available again the resource will be auto-magically moved back?

--
Chet Burgess
cfb at liquidreality.org