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.
