[Linux-cluster] Re: [cgl_discussion] Re: [dcl_discussion] Cluster
phillips at redhat.com
Wed Aug 11 11:54:08 PDT 2004
On Wednesday 11 August 2004 12:18, John Cherry wrote:
> On Tue, 2004-08-10 at 13:58, Lars Marowsky-Bree wrote:
> > On 2004-08-10T13:49:26, John Cherry <cherry at osdl.org> said:
> > > While these common components all have RHAT/Sistina roots, these
> > > components are in the best position for mainline acceptance. As
> > > APIs are defined for these services, other implementations could
> > > also be used (the vfs model).
> > This isn't quite true. cman as a whole is not quite in the best
> > position for mainline acceptance; actually, most isn't.
That's accurate, that's why I keep beating on the 'read the code' issue,
not to mention trying it, and hacking it.
> I realize that cman will probably be at "alpha" level maturity in
> October, but we did not discuss any other possibilities for kernel
> level membership/communication.
I believe it was briefly mentioned that we mainly use bog-standard tcp
socket streams for communication. I'll add that various subsystems
incorporate their own reliability logic, and maybe one day far from
now, we'll be able to unify all of that. For now, it's a little
ambitions, not to mention unnecessary.
> linux-ha and openais have user level
> components. I suppose SSI membership could be considered as a
> candidate implementation for the initial merge, but the consensus was
> that we would focus on cman, define the APIs, and use cman as the
> initial membership/communication module. Multiple implementations
> would be good and if we do a good job defining the APIs (membership,
> communication, fencing), other membership services could be used down
> the road.
IMHO, for the time being only failure detection and failover really has
to be unified, and that is CMAN, including interaction with other bits
and pieces, i.e., Magma and fencing, and hopefully other systems like
Lars' SCRAT. As far as CMAN goes, Lars and Alan seem to be the main
parties outside Red Hat. Lon and Patrick are most active inside Red
Hat. I think we'd advance fastest if they start hacking each other's
code (anybody I just overlooked, please bellow).
However it goes, this process is going to take time. Two months would
be blindingly fast, and that is before we even think about pushing to
> Was I at a different summit than you attended, or is that your
> understanding of the strategic direction of moving Linux to be a
> "clusterable kernel"?
That seemed to be the concensus at the summit I attended. Note that
we've already got the basic changes to the VFS in place, with a few
I still think that gdlm can go to Andrew before CMAN, however that is
contingent on working out a way to invert the link-level dependency on
CMAN so that the OCFS2 guys and people who want to experiment with
dlm-style coding can try it without being forced to adopt a lot of
other, less stable infrastructure at the same time. This will be going
forward in parallel with the CMAN api work.
> How can we have membership without some form of communication
> service? (communication-based membership or connectivity-based
> The low level cluster communication mechanism is one of those
> services that I believe we need an API definition for since it will
> also be leveraged by higher level services such as group messaging or
> an event service.
> So you can call the core service "membership", but what we really
> need is membership/communication, which is what cman provides. Do
> you have another suggestion for this? TIPC + membership?
I think you really mean "connection manager", not "communication
service" I'll step back from this now and watch you guys sort it
More information about the cgl_discussion