[Pacemaker] Suggestion to improve movement of booth

[yusuke iida]

Hi, Jiaju

Could you please reply to this message?

Regards,
Yusuke.

2013/1/28 yusuke iida <yusk.iida at gmail.com>:
> Hi, Jiaju
>
> 2013/1/15 Jiaju Zhang <jjzhang at suse.de>:
>> On Tue, 2013-01-15 at 11:28 +0900, yusuke iida wrote:
>>> 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.
>>
>> Understood, this is an important fix. However, it seems that there is an
>> easier way to fix this, just change the return value of "lease_promise",
>> that is to say, return -1 when having leased.
>>
>> I'm inclined to do so because the new function "lease_is_leased"
>> basically did the same thing with "lease_promise", but "lease_promise"
>> returned a wrong value currently. What do you think?;)
> I reconsidered this processing.
> To be sure, "lease_is_leased" is redundant.
> I moved a function of "lease_is_leased" to "lease_promise".
> I'm not sure I should leave the "ability to get re-lease" existing.
> With the patch which I made, a function is changed by the configuration file.
>
> The patch which I made again is here.
> https://github.com/yuusuke/booth/commit/f99e74f38b51b89bf2deccb0eb2249a12fb45bb6
>
>>
>> BTW, don't forget to add your Signed-off-by line and check the patch
>> with checkpatch.pl, this will make booth to use the same coding style;)
> I understood it.
>
> BTW, we have noticed that some patents relevant to paxos exist, while
> investigating about the technology of paxos.
> Has the paxos algorithm used by booth cleared the problem about such a patent?
>
> Regards,
> Yusuke
>>
>> Thanks,
>> Jiaju
>>
>>
>>
>
> --
> ----------------------------------------
> METRO SYSTEMS CO., LTD
>
> Yusuke Iida
> Mail: yusk.iida at gmail.com
> ----------------------------------------



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

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