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

Re: [Cluster-devel] STABLE2 cluster branch

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.


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

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