[Cluster-devel] STABLE2 cluster branch
Christine Caulfield
ccaulfie at redhat.com
Wed Mar 5 11:39:32 UTC 2008
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.
>>
>> 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.
It might be easiest to have separate files for the 'openais' and
'corosync' interfaces in that case. We'll see.
Chrissie
More information about the Cluster-devel
mailing list