[Cluster-devel] STABLE2 cluster branch

[Fabio M. Di Nitto]

On Mon, 3 Mar 2008, Steven Dake wrote:

> On Mon, 2008-03-03 at 09:10 -0600, David Teigland wrote:
>> On Sat, Mar 01, 2008 at 02:52:05PM -0700, Steven Dake wrote:
>>> This is reasonable but requires having quite a bit of conditional
>>> compilation in cman and other tools.  I don't know if anyone is working
>>> on this, but I'd imagine maintenance of such a scheme would be
>>> complicated since the trunk of whitetank is about to rev into tigh speed
>>> modification requiring different dependencies of the gfs userland.
>>>
>>> If we are to say this conditional compilation "only works with trunk of
>>> openais up to a certain point such as version 0.84" then that certain
>>> point becomes a "branch point" which I really do not want.  What I
>>> prefer is that trunk of gfs userland be munged to work with the new
>>> corosync dependency and once that has all stabilized create a new branch
>>> of userland to work with the corosync 1.0 infrastructure.  The complete
>>> software suite then would be "stable3" + "corosync 1.X" + "trunk of
>>> openais ais services" for the checkpoint service.
>>
>> So it sounds like the next stable release of openais will be in the new
>> form of corosync + openais?  Will Fedora 9 have whitetank or the new
>> corosync+openais release?
>>
>> We definately need to do a release or two of cluster-2.y.z from STABLE2
>> based on openais whitetank.  Then, once a stable release of
>> corosync+openais exists, I see sense in either:
>>
>> 1. switching STABLE2 from whitetank to the corosync+openais release
>> 2. supporting both whitetank and corosync in STABLE2 somehow, perhaps
>>    dropping whitetank support after a while
>>
>> 1 would make most sense if F9 has corosync, 2 would make most sense if F9
>> has whitetank.
>>
>
> I agree we need to release stable2 with the current whitetank.
>
> While I would like to have corosync enabled for F9, it wont be ready in
> time for that distribution.  The corosync tree hasn't yet emerged so
> targeting f9 is a bit premature.
>
> Unfortunately this creates quite a bit more work WRT ifdeffing of the
> code to support either corosync or whitetank.  I don't mind helping with
> the rest of the infrastructure conversion to corosync in the trunk of
> the gfs tree, but keeping stable2 operational with both sounds like a
> lot of difficult work.

Indeed, but diff will help us here. We have the exact history of patches 
that were required to switch from whitetank to trunk. We just need to 
rediff them manually with --ifdef= and reapply to stable2.

> If the distributions really need it, however, it is something we should
> address.

Well some distributions do actually ship trunk because of the several 
endianess and alignment bug fixes that are not in whitetank.

>  I believe really what we need is a stable 3 which is branched
> from trunk to work with corosync once corosync and trunk have met some
> level of capabilities (like it compiles, works, and passes heavy stress
> testing).  But maybe this creating of stable3 is more work then making
> stable2 work with both openais and corosync.

Given the branch management history of this project, i don't believe in a 
stable3 branch. stable2 is already out of sync with bug fixes and it's 
just been created.

Very few developers, and it's just a matter of fact, remember to push 
fixes to all branches. No complain involved. it's just how it used to work 
in the past :)))

> In my opinion though, a stable branch shouldn't add features or entirely
> new foundations for the code such as a new infrastructure.  So I'm not
> sure why to call it stable2 if in fact it is a "stable trunk" :)

You have point, but i think stable-trunk is what we really need.

if we look at the branch from another perspective, we will keep updating 
the kernel modules to run with .25 and future kernel releases. I don't see 
why it should be any different for openais.

The stack has clearly a bunch of very strong depends that need to be 
addressed.

Fabio

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