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

Re: [Cluster-devel] STABLE2 cluster branch



On Mon, Mar 03, 2008 at 10:07:26AM -0700, 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.
> 
> 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.

We already have two parallel branches of the cluster2 (second generation)
code: RHEL5 and STABLE2; we really don't want a third.

Given that, we have four options for STABLE2:
1. work with whitetank
2. work with corosync
3. use ifdefs to work with both at once
4. work with whitetank for now, switch to corosync once it's stable


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

As I mentioned above, I was assuming we'd wait to convert STABLE2 to
corosync until there was actually a stable, released version of it.



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