[Cluster-devel] STABLE2 cluster branch

[Fabio M. Di Nitto <fabbione@ubuntu.com>]

On Mon, 3 Mar 2008, 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.

Clearly STABLE2 is running on truck and what would be corosync+openais 
hopefully in not too long from now.

Does it make sense to roll back to whitetank and back in such short time? 
Let's keep in mind that if we push out stable releases into distro with 
the stable2+whitetank combo, i assume we will need to keep supporting it 
for a while before turning stable2 to support corosync.

Hence my general idea of just #ifdeffing openais support in stable2 to 
handle both whitetank and corosync at build time (no runtime detection) 
and let the users/distros decide what combo they prefer.

If you look at it:

whitetank does not change. stable2 support will only need roll back.

trunk changes in openais. our master follows openais trunk. Commit the 
diff into stable2. It's going to be just a bit painful in the very 
beginning but at the end it's a matter of a cherry pick or almost.

Fabio

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