From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christine Caulfield Date: Wed, 05 Mar 2008 16:23:12 +0000 Subject: [Cluster-devel] STABLE2 cluster branch In-Reply-To: <47CE8674.3070308@redhat.com> References: <20080222204806.GA23535@redhat.com> <1204360417.31162.16.camel@balance> <1204408326.31162.25.camel@balance> <20080303151028.GA31888@redhat.com> <20080303163019.GB31888@redhat.com> <47CD5126.7020908@redhat.com> <1204660786.3874.1.camel@balance> <47CE8674.3070308@redhat.com> Message-ID: <47CEC8F0.3070900@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Christine Caulfield wrote: > Steven Dake wrote: >> 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. >>> Here's a first pass at a patch to make STABLE2 work with openais trunk and whitetank. please give it a go (or at least a look) if you can. -- Chrissie -------------- next part -------------- A non-text attachment was scrubbed... Name: stable2.diff Type: text/x-patch Size: 4705 bytes Desc: not available URL: