[Cluster-devel] STABLE2 cluster branch

[Cluster-devel] STABLE2 cluster branch

[David Teigland]

I've created a new STABLE2 branch from master in the new cluster.git.
The point of STABLE2 is:

  - build/run with the current stable release of openais, (now 0.80.3)
  - build/run with the current stable release of the kernel, (now 2.6.24)

I think we're in good shape already for the kernel, but some work is
needed for compatibility with openais 0.80.3.

Most of the commits that are made to the RHEL5 branch should also be made
to STABLE2.  New things developed on the master branch would probably not
be appropriate for STABLE2.

I plan to do tarball releases from the STABLE2 branch (cluster-2.y.0).  As
soon as we get it working with openais 0.80.3 and kernel 2.6.24, we'll
release cluster-2.02.00.

My ultimate hope is that these released tarballs will form the basis for
distribution packaging.

Dave

[Cluster-devel] STABLE2 cluster branch

[Fabio M. Di Nitto]

Hi guys,

On Fri, 22 Feb 2008, David Teigland wrote:

> I've created a new STABLE2 branch from master in the new cluster.git.

thanks for this work...

> The point of STABLE2 is:
>
>  - build/run with the current stable release of openais, (now 0.80.3)

I think i would really like to be able to detect this at build time. I 
know as a project we don't usually add #ifdef version > 1.0 kind of things 
but some distributions already have openais 0.82 around and a downgrade to 
follow the stable2 branch could be complex.

I don't see creating another branch is the right solution as it will 
involve the extra overhead for it.

> I think we're in good shape already for the kernel, but some work is
> needed for compatibility with openais 0.80.3.

Is anybody actually working on this?

> Most of the commits that are made to the RHEL5 branch should also be made
> to STABLE2.  New things developed on the master branch would probably not
> be appropriate for STABLE2.

Also bug fixes and clean up commits in master should go into the stable2 
branch. There are already a good bunch of candidates for inclusion.

> I plan to do tarball releases from the STABLE2 branch (cluster-2.y.0).  As
> soon as we get it working with openais 0.80.3 and kernel 2.6.24, we'll
> release cluster-2.02.00.

cool.

> My ultimate hope is that these released tarballs will form the basis for
> distribution packaging.

perfect!

thanks
Fabio

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

[Cluster-devel] STABLE2 cluster branch

[Steven Dake]

On Sat, 2008-03-01 at 07:13 +0100, Fabio M. Di Nitto wrote:
> Hi guys,
> 
> On Fri, 22 Feb 2008, David Teigland wrote:
> 
> > I've created a new STABLE2 branch from master in the new cluster.git.
> 
> thanks for this work...
> 
> > The point of STABLE2 is:
> >
> >  - build/run with the current stable release of openais, (now 0.80.3)
> 
> I think i would really like to be able to detect this at build time. I 
> know as a project we don't usually add #ifdef version > 1.0 kind of things 
> but some distributions already have openais 0.82 around and a downgrade to 
> follow the stable2 branch could be complex.
> 
> I don't see creating another branch is the right solution as it will 
> involve the extra overhead for it.
> 
> > I think we're in good shape already for the kernel, but some work is
> > needed for compatibility with openais 0.80.3.
> 
> Is anybody actually working on this?
> 

I believe the answer is no but I am not sure if Dave or Chrissie are
working on this effort.

I continue to maintain and work on the stable branch of openais
(whitetank 0.80.3), but I don't know of the efforts Dave is talking
about or even what was branched to create stable2.  I assume it is the
current trunk of the gfs userland tree.  In this case, the current
trunk(stable2) is meant to work against the trunk of openais. 

_No_ new features are going into whitetank at all so whatever is in
stable 2 must be modified to work with the whitetank branch.

The "trunk" of openais/corosync will work with the trunk of the git
repo.  This is the only effort underway now involving openais.

I __am not creating new branches__ of openais to work specifically with
stable 2 or backporting any feature additions that are currently in
trunk.  The only porting that will take place is forward ports of bug
fixes in the whitetank branch that are not in the trunk.

Finally whitetank is frozen to feature additions that are not critical
to user requirements.  Only bug fixes go into whitetank.  Our full
commit policy WRT various branches can be found here:

http://www.openais.org/doku.php?id=dev:commit_policy

Regards
-steve

> > Most of the commits that are made to the RHEL5 branch should also be made
> > to STABLE2.  New things developed on the master branch would probably not
> > be appropriate for STABLE2.
> 
> Also bug fixes and clean up commits in master should go into the stable2 
> branch. There are already a good bunch of candidates for inclusion.
> 
> > I plan to do tarball releases from the STABLE2 branch (cluster-2.y.0).  As
> > soon as we get it working with openais 0.80.3 and kernel 2.6.24, we'll
> > release cluster-2.02.00.
> 
> cool.
> 
> > My ultimate hope is that these released tarballs will form the basis for
> > distribution packaging.
> 
> perfect!
> 
> thanks
> Fabio
> 
> --
> I'm going to make him an offer he can't refuse.
> 

[Cluster-devel] STABLE2 cluster branch

[Fabio M. Di Nitto]

On Sat, 1 Mar 2008, Steven Dake wrote:

> On Sat, 2008-03-01 at 07:13 +0100, Fabio M. Di Nitto wrote:
>> Hi guys,
>>
>> On Fri, 22 Feb 2008, David Teigland wrote:
>>
>>> I've created a new STABLE2 branch from master in the new cluster.git.
>>
>> thanks for this work...
>>
>>> The point of STABLE2 is:
>>>
>>>  - build/run with the current stable release of openais, (now 0.80.3)
>>
>> I think i would really like to be able to detect this at build time. I
>> know as a project we don't usually add #ifdef version > 1.0 kind of things
>> but some distributions already have openais 0.82 around and a downgrade to
>> follow the stable2 branch could be complex.
>>
>> I don't see creating another branch is the right solution as it will
>> involve the extra overhead for it.
>>
>>> I think we're in good shape already for the kernel, but some work is
>>> needed for compatibility with openais 0.80.3.
>>
>> Is anybody actually working on this?
>>
>
> I believe the answer is no but I am not sure if Dave or Chrissie are
> working on this effort.
>
> I continue to maintain and work on the stable branch of openais
> (whitetank 0.80.3), but I don't know of the efforts Dave is talking
> about or even what was branched to create stable2.

> I assume it is the
> current trunk of the gfs userland tree.  In this case, the current
> trunk(stable2) is meant to work against the trunk of openais.

STABLE2 was branched from trunk with the idea in mind to revert the 
minimal amount of changes in the cluster stack to work with openais 
whitetank.

>
> _No_ new features are going into whitetank at all so whatever is in
> stable 2 must be modified to work with the whitetank branch.

we already know this. nobody is asking you to change anything here. It's 
the branch in cluster that needs to change.

> The "trunk" of openais/corosync will work with the trunk of the git
> repo.  This is the only effort underway now involving openais.

nothing new here either.

>
> I __am not creating new branches__ of openais to work specifically with
> stable 2 or backporting any feature additions that are currently in
> trunk.  The only porting that will take place is forward ports of bug
> fixes in the whitetank branch that are not in the trunk.

I think you misunderstood completely my email. Nobody is asking you to 
change anything in openais to handle the stable2 branch.

The original plan for the STABLE2 branch is to work with openais whitetank 
stable branch.

What i did ask was to change this original plan to make it so that STABLE2 
branch can work with both whitetank and openais trunk by detecting the 
openais version at build time.

> Finally whitetank is frozen to feature additions that are not critical
> to user requirements.  Only bug fixes go into whitetank.  Our full
> commit policy WRT various branches can be found here:
>
> http://www.openais.org/doku.php?id=dev:commit_policy

nothing new here either..

Fabio

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

[Cluster-devel] STABLE2 cluster branch

[Steven Dake]

On Sat, 2008-03-01 at 17:31 +0100, Fabio M. Di Nitto wrote:
>                              From: 
> Fabio M. Di Nitto
> <fabbione@ubuntu.com>
>                                To: 
> Steven Dake <sdake@redhat.com>
>                                Cc: 
> Fabio M. Di Nitto
> <fabbione@ubuntu.com>, David
> Teigland <teigland@redhat.com>,
> cluster-devel at redhat.com
>                           Subject: 
> Re: [Cluster-devel] STABLE2 cluster
> branch
>                              Date: 
> Sat, 1 Mar 2008 17:31:22 +0100
> (CET)  (09:31 MST)
> 
> 
> On Sat, 1 Mar 2008, Steven Dake wrote:
> 
> > On Sat, 2008-03-01 at 07:13 +0100, Fabio M. Di Nitto wrote:
> >> Hi guys,
> >>
> >> On Fri, 22 Feb 2008, David Teigland wrote:
> >>
> >>> I've created a new STABLE2 branch from master in the new
> cluster.git.
> >>
> >> thanks for this work...
> >>
> >>> The point of STABLE2 is:
> >>>
> >>>  - build/run with the current stable release of openais, (now
> 0.80.3)
> >>
> >> I think i would really like to be able to detect this at build
> time. I
> >> know as a project we don't usually add #ifdef version > 1.0 kind of
> things
> >> but some distributions already have openais 0.82 around and a
> downgrade to
> >> follow the stable2 branch could be complex.
> >>
> >> I don't see creating another branch is the right solution as it
> will
> >> involve the extra overhead for it.
> >>
> >>> I think we're in good shape already for the kernel, but some work
> is
> >>> needed for compatibility with openais 0.80.3.
> >>
> >> Is anybody actually working on this?
> >>
> >
> > I believe the answer is no but I am not sure if Dave or Chrissie are
> > working on this effort.
> >
> > I continue to maintain and work on the stable branch of openais
> > (whitetank 0.80.3), but I don't know of the efforts Dave is talking
> > about or even what was branched to create stable2.
> 
> > I assume it is the
> > current trunk of the gfs userland tree.  In this case, the current
> > trunk(stable2) is meant to work against the trunk of openais.
> 
> STABLE2 was branched from trunk with the idea in mind to revert the 
> minimal amount of changes in the cluster stack to work with openais 
> whitetank.
> 
> >
> > _No_ new features are going into whitetank at all so whatever is in
> > stable 2 must be modified to work with the whitetank branch.
> 
> we already know this. nobody is asking you to change anything here.
> It's 
> the branch in cluster that needs to change.
> 
> > The "trunk" of openais/corosync will work with the trunk of the git
> > repo.  This is the only effort underway now involving openais.
> 
> nothing new here either.
> 
> >
> > I __am not creating new branches__ of openais to work specifically
> with
> > stable 2 or backporting any feature additions that are currently in
> > trunk.  The only porting that will take place is forward ports of
> bug
> > fixes in the whitetank branch that are not in the trunk.
> 
> I think you misunderstood completely my email. Nobody is asking you
> to 
> change anything in openais to handle the stable2 branch.
> 
> The original plan for the STABLE2 branch is to work with openais
> whitetank 
> stable branch.
> 
> What i did ask was to change this original plan to make it so that
> STABLE2 
> branch can work with both whitetank and openais trunk by detecting
> the 
> openais version at build time.
> 

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.

Regards
-steve

> > Finally whitetank is frozen to feature additions that are not
> critical
> > to user requirements.  Only bug fixes go into whitetank.  Our full
> > commit policy WRT various branches can be found here:
> >
> > http://www.openais.org/doku.php?id=dev:commit_policy
> 
> nothing new here either..
> 
> Fabio
> 
> --
> I'm going to make him an offer he can't refuse. 

[Cluster-devel] STABLE2 cluster branch

[David Teigland]

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

[Cluster-devel] STABLE2 cluster branch

[Fabio M. Di Nitto]

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.

Fabio

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

[Cluster-devel] STABLE2 cluster branch

[David Teigland]

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.

Yeah, good point.

[Cluster-devel] STABLE2 cluster branch

[Steven Dake]

On Mon, 2008-03-03 at 09:10 -0600, 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.
> 

I agree we need to release stable2 with the current whitetank.

While I would like to have corosync enabled for F9, it wont be ready in
time for that distribution.  The corosync tree hasn't yet emerged so
targeting f9 is a bit premature.

Unfortunately this creates quite a bit more work WRT ifdeffing of the
code to support either corosync or whitetank.  I don't mind helping with
the rest of the infrastructure conversion to corosync in the trunk of
the gfs tree, but keeping stable2 operational with both sounds like a
lot of difficult work.

If the distributions really need it, however, it is something we should
address.  I believe really what we need is a stable 3 which is branched
from trunk to work with corosync once corosync and trunk have met some
level of capabilities (like it compiles, works, and passes heavy stress
testing).  But maybe this creating of stable3 is more work then making
stable2 work with both openais and corosync.

In my opinion though, a stable branch shouldn't add features or entirely
new foundations for the code such as a new infrastructure.  So I'm not
sure why to call it stable2 if in fact it is a "stable trunk" :)

Regards
-steve

Regards
-steve

> Dave
> 

[Cluster-devel] STABLE2 cluster branch

[David Teigland]

On Mon, Mar 03, 2008 at 10:07:26AM -0700, Steven Dake wrote:
> On Mon, 2008-03-03 at 09:10 -0600, 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.
> > 
> 
> I agree we need to release stable2 with the current whitetank.
> 
> While I would like to have corosync enabled for F9, it wont be ready in
> time for that distribution.  The corosync tree hasn't yet emerged so
> targeting f9 is a bit premature.
> 
> Unfortunately this creates quite a bit more work WRT ifdeffing of the
> code to support either corosync or whitetank.  I don't mind helping with
> the rest of the infrastructure conversion to corosync in the trunk of
> the gfs tree, but keeping stable2 operational with both sounds like a
> lot of difficult work.
> 
> If the distributions really need it, however, it is something we should
> address.  I believe really what we need is a stable 3 which is branched
> from trunk to work with corosync once corosync and trunk have met some
> level of capabilities (like it compiles, works, and passes heavy stress
> testing).  But maybe this creating of stable3 is more work then making
> stable2 work with both openais and corosync.

We already have two parallel branches of the cluster2 (second generation)
code: RHEL5 and STABLE2; we really don't want a third.

Given that, we have four options for STABLE2:
1. work with whitetank
2. work with corosync
3. use ifdefs to work with both at once
4. work with whitetank for now, switch to corosync once it's stable


> In my opinion though, a stable branch shouldn't add features or entirely
> new foundations for the code such as a new infrastructure.  So I'm not
> sure why to call it stable2 if in fact it is a "stable trunk" :)

As I mentioned above, I was assuming we'd wait to convert STABLE2 to
corosync until there was actually a stable, released version of it.

[Cluster-devel] STABLE2 cluster branch

[Fabio M. Di Nitto]

On Mon, 3 Mar 2008, Steven Dake wrote:

> On Mon, 2008-03-03 at 09:10 -0600, 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.
>>
>
> I agree we need to release stable2 with the current whitetank.
>
> While I would like to have corosync enabled for F9, it wont be ready in
> time for that distribution.  The corosync tree hasn't yet emerged so
> targeting f9 is a bit premature.
>
> Unfortunately this creates quite a bit more work WRT ifdeffing of the
> code to support either corosync or whitetank.  I don't mind helping with
> the rest of the infrastructure conversion to corosync in the trunk of
> the gfs tree, but keeping stable2 operational with both sounds like a
> lot of difficult work.

Indeed, but diff will help us here. We have the exact history of patches 
that were required to switch from whitetank to trunk. We just need to 
rediff them manually with --ifdef= and reapply to stable2.

> If the distributions really need it, however, it is something we should
> address.

Well some distributions do actually ship trunk because of the several 
endianess and alignment bug fixes that are not in whitetank.

>  I believe really what we need is a stable 3 which is branched
> from trunk to work with corosync once corosync and trunk have met some
> level of capabilities (like it compiles, works, and passes heavy stress
> testing).  But maybe this creating of stable3 is more work then making
> stable2 work with both openais and corosync.

Given the branch management history of this project, i don't believe in a 
stable3 branch. stable2 is already out of sync with bug fixes and it's 
just been created.

Very few developers, and it's just a matter of fact, remember to push 
fixes to all branches. No complain involved. it's just how it used to work 
in the past :)))

> In my opinion though, a stable branch shouldn't add features or entirely
> new foundations for the code such as a new infrastructure.  So I'm not
> sure why to call it stable2 if in fact it is a "stable trunk" :)

You have point, but i think stable-trunk is what we really need.

if we look at the branch from another perspective, we will keep updating 
the kernel modules to run with .25 and future kernel releases. I don't see 
why it should be any different for openais.

The stack has clearly a bunch of very strong depends that need to be 
addressed.

Fabio

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

[Cluster-devel] STABLE2 cluster branch

[Christine Caulfield]

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

[Cluster-devel] STABLE2 cluster branch

[Steven Dake]

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

[Cluster-devel] STABLE2 cluster branch

[Christine Caulfield]

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

[Cluster-devel] STABLE2 cluster branch

[Christine Caulfield]

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: <http://listman.redhat.com/archives/cluster-devel/attachments/20080305/3b6d75d2/attachment.bin>