[Cluster-devel] [RFC] Common cluster connection handler API

[Fabio M. Di Nitto <fdinitto@redhat.com>]

On Fri, 27 Jun 2008, David Teigland wrote:

> On Fri, Jun 27, 2008 at 08:19:36PM +0200, Fabio M. Di Nitto wrote:
>>> I was actually hoping that with no more ccsd there'd be no more
>>> "connecting" to ccs, but that's probably a topic for one of the ccs
>>> meetings...
>>
>> The only partial advantage you have, as i documented and wrote to
>> cluster-devel, is that if you are connected to cman and cman_is_active,
>> you are guaranteed 99.9% to connected to ccs without problems (only
>> reason for rejection would be lack of resources on the machine, but at
>> that point you have more serious issues to worry about).
>
> Oops, sorry, I'm still not thinking straight about the new ccs... yeah,
> that makes sense that if cman is up then ccs should be there, since both
> are openais extensions.  I'm curious, after cman_init() succeeds, what
> more does cman_is_active() mean?  In practice would cman_init() ever be
> ok, but cman_is_active() not be ok?
>

There is a small window while cman has setup the sockets and you can 
connect and when it is actually configured, running and ready to process 
data.

cman_is_active will return 1 only when the whole startup process is 
completed and all of aisexec is running.

I think it is unlikely to happen but it can happen and it is a race 
condition we want to avoid. As a consequence we know that the objdb has 
been filled up with data.

The new ccs could theoretically load a standalone version of the objdb 
(without cman or starting aisexec) but:

1) we would have to replicate all the information to know from which 
plugin to load the configuration everywhere.

2) the startup sequence would be much more complex and racy (load, unload, 
reload etc.)

3) basically all our daemons need cman. so turning this point into void.

I think all of the above is undesireable.

Fabio

--
I'm going to make him an offer he can't refuse.