[Pacemaker] Behavior booth when the temporary ACT site down happened.

[Jiaju Zhang]

On Thu, 2012-07-12 at 17:14 +0900, Yuichi SEINO wrote:
> Hi Jiaju,
> 
> Sorry, I add supplement.
> 
> Site A down is that all clusters in Site A is power-off at the same
> time. If the start-up of Site A succeed within the expire date, I
> would like to know whether Site A can join booth of cluster. And
> whether Site A can keep a ticket.

Oh, if you have powered off all the nodes in Site A, it can explain why
there is no the information on CIB in bug#5082 ;)

Site A can join the booth cluster, given that the catch-up has been
finished. Since Site A was recovered within the expire date, so no other
site try to acquire the ticket for the time being, so Site A may get the
ticket via the voting again.

I understand your question, if Site A can still keep the original ticket
but not go into the next round voting, that would be much better than
current behavior. It needs site A to analyze all the information that
just caught up, to determine if that ticket really belongs to himself or
not. This feature is in my todo list, I'm planning to refactor the
catch-up code, together with some refactoring of the transport layer in
the next development.

Thanks,
Jiaju
     
> 
> Sincerely,
> Yuichi
> 
> 2012/7/11 Jiaju Zhang <jjzhang at suse.de>:
> > On Wed, 2012-07-11 at 17:46 +0900, Yuichi SEINO wrote:
> >> Hi Jiaju,
> >>
> >> 2012/7/11 Jiaju Zhang <jjzhang at suse.de>:
> >> > On Wed, 2012-07-11 at 11:47 +0900, Yuichi SEINO wrote:
> >> >> Hi Jiaju,
> >> >>
> >> >> My environment consist of Site A, Site B, and Site C(Arbitrator). And
> >> >> I granted a ticket to Site A. And then I execute Site A down.
> >> >> Secondly, I start up Site A within the expire date.  then the state of
> >> >> Site A is that the ticket is revoked. So Site B is granted after the
> >> >> ticket expired.
> >> >>
> >> >> I would like to know if this behavior is correct.
> >> >>
> >> >> As I see it, If Site A succeed in catchup, Site A should keep a ticket
> >> >> after the ticket expired.
> >> >>
> >> >
> >> > Oh, this should not be a bug, but in the future we may add some
> >> > configuration options or some policy to let it work as what the user
> >> > expected. There is a small window from the original ticket owner decided
> >> > to renew to the ticket expires. Although you get the Site A started
> >> > within the expire date, but it approaches the expire very soon, so no
> >> > enough time to renew that ticket.
> >> >
> >> > Currently that small window is 20% of the expire time, but it should be
> >> > able to be configured by the users. So, in the future development, I'm
> >> > planning to make it configurable and also add more policy on the renew
> >> > logic.
> >> >
> >>
> >> For example,  if the expire date is 10 min,  Site A can keep a ticket
> >> when Site A is repaired until 8 min.
> >> Am I correct in thinking this?
> >
> > Yes.
> >
> >>
> >> However,  I found an another problem　when I am looking the log.  Site
> >> A never store a ticket information in cib after Site A is restart.
> >> Tentatively, this log put in bugzilla.
> >>
> >> http://bugs.clusterlabs.org/show_bug.cgi?id=5082
> >
> > OK, I'll look into this as well;)
> >
> > Thanks,
> > Jiaju
> >
> 
> 
>