[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Cluster-devel] STABLE2 cluster branch



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.

If the distributions really need it, however, it is something we should
address.  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.

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" :)

Regards
-steve

Regards
-steve

> Dave
> 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]