[Pacemaker] [ANNOUNCE] The Booth Cluster Ticket Manager - part of multi-site support in pacemaker

[Jiaju Zhang]

On Wed, 2012-02-08 at 17:05 +0900, 李泰勲 wrote:
> Hi Jiaju
> 
> Thank you for your reply.
> 
> 
> (2012/02/08 15:11), Jiaju Zhang wrote:
> > On Tue, 2012-02-07 at 11:09 +0900, 李泰勲 wrote:
> >> Hi Jiaju
> >>
> >> I am testing about working of booth while investigating booth source code.
> >>
> >> I don't understand ticket grant and revoke process perfectly that is 
> >> related to connecting each booth
> >> so I would like to know booth's working that would be matching your 
> >> offering source code.
> >>
> >> Could you give me information about booth sequences that would be the 
> >> ticket's grant,revoke,lease logic and working of ticket's expiry time.
> > General speaking, you would want to grant some ticket on certain site
> > initially, which means the corresponding resources can be run at that
> > site. For the lease logic, ticket granting means that site has the
> > ticket lease. The lease has an expiry time, after the expiry time, that
> > lease is expired and the corresponding resources can't be run at that
> > site any longer.
> > If the site which has the original ticket granting is alive, it will
> > renew the lease before the ticket expired, but if that site is broken,
> > when the lease is expired, the lease logic will go into election stage
> > and a new site will get the ticket lease, thus the resources will be
> > able to run at the new site.  
> > You can revoke the ticket from the site as well, but in most cases, you
> > may not want to do this. The possible scenario I can think of is when
> > the admin wants to do some maintenance work, or wants to do the ticket
> > management manually.
> We have understood booth working as your reply.
> but I am wondering booth working process when it occurred splitbrain in
> each sites.
> 
> for example.
> 
> siteA has ticketA grant.
> siteB has no grant.
> siteB is Arbitrator.

Well, site B could not be the arbitrator. Arbitrator doesn't need to be
a cluster site, it can be just a machine, but it should be in the 3rd
site;)

> 
> if siteA connection fails and isolated from each sites,
> automatically failover to siteB.
> but ticketA did not revoke in siteA.

The ticketA will expire in site A and then it will be revoked. The
algorithm is able to guarantee before the ticket is granted to siteB, it
has been revoked on siteA.
However, current code has some bug on the ticket revoking;) I have an
unfinished patch in hand and plan to submit it this week.  

> 
> I think that ticket granting is alive in siteB and revoking in siteA.
> Is that right that I think?
> >> when do you think the booth's working is fixed and completed ?
> > Oh, I have not finished it yet;) But I'm still working on it, since I
> > also have some other tasks, maybe the progress is not fast these days;)
> >
> >> Is there anything to help you about booth's implementation or etc?
> > The framework is finished, but there are still some bugs in it, so the
> > code may not work for you for the time being, I'll be more than happy if
> > anyone can help to fix bugs, or develop new features;) 
> > For the short term, I think adding the man pages, documentation and some
> > automation test programs/scripts would be very good. For the long term,
> > I also have something new in my mind, maybe I should add a TODO to
> > document it later.
> >
> > Well, the primary thing for now is to fix current bugs to make it really
> > working, and I myself will spend more time on it these two weeks;)
> If you have any bugs that you recognized already,Please you give me that
> information?

OK. A known issue is about the ticket revoking which I'm working on.
Others I think I should look through the novell bugzilla first, and then
send you the links or the description if you don't have a novell
bugzilla account. Sure you're welcome to report issue and send patch
here;)

> And If we find booth bugs as we will send the report and patch as possible.

Many many thanks;)

Thanks,
Jiaju