bOn Tue, 2008-03-04 at 13:39 +0000, Christine Caulfield wrote: > David Teigland wrote: > > On Mon, Mar 03, 2008 at 05:10:54PM +0100, Fabio M. Di Nitto wrote: > >>>> 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. > > > > It shouldn't be /toooo/ bad. The main thing that keeps cman from > compiling against whitetank is the lack of logsys. We don't need to > backport logsys to whitetank, just provide a compatibility API for it. > Given that most of that is log_printf() that's not going to be very > arduous I hope. With luck (and I haven't check this in detail) I hope it > can be isolated to the logging.[ch] files. > > Chrissie >
When corosync 1.0 is released the entire ABI used to make plugins will change as well as the recovery system. I am not backporting or making compatibility interfaces for these things. So the code will have to be ifdefed to deal with this condition, or a stable3 branch will have to be branched off trunk when corosync is released. Regards -steve
