[Pacemaker] Suggestion to improve movement of booth

[yusuke iida]

Hi, Jiaju

2013/1/11 Jiaju Zhang <jjzhang at suse.de>:
> Hi Yusuke,
>
> Sorry for the late reply;)
>
> On Mon, 2013-01-07 at 13:50 +0900, yusuke iida wrote:
>> Hi, Jiaju
>>
>> When the proposal was conflict, I want to keep on the site of the
>> original lease.
>> I do not want to generate a revoke when maintained.
>>
>>
>> I made a patch according to a thought of "5.2 Master lease" described
>> in the next article.
>> It means that it prevents you from accepting new suggestion until a
>> time limit of lease expires.
>
> Exactly.
>
>>
>> http://www.read.seas.harvard.edu/~kohler/class/08w-dsi/chandra07paxos.pdf
>>
>> Is there anything wrong with this idea?
>
> This idea is totally right. But we have already implemented it. When the
> master exists and is still in its lease, if some other one wants to be
> the master and sent the "prepare" message, the acceptor will told him
> "oh, we have already had a master" by setting "hdr->leased = 1" in his
> respond message, actually this is a rejection, then the one trying to be
> master won't succeed.
I understand these specifications.
However, by the present specification, when returning "hdr->leased =
1", "highest_promised" is updated by ballot of new "prepare".
When "highest_promised" is updated, reaccession of lease is carried
out in original masters.
Since revoke is performed at this time, the node which the resource
was start(ing) is STONITH(ed) by loss-policy=fence.
As for this, the stop of temporary service happens.
To avoid this, I've implemented the change not to do to re-acquire the lease.

Regards,
Yusuke
>
> It seems your patch is also doing this, right?
>
> Thanks,
> Jiaju
>



--
----------------------------------------
METRO SYSTEMS CO., LTD

Yusuke Iida
Mail: yusk.iida at gmail.com
----------------------------------------