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. Dave
