* [Cluster-devel] cluster-2.03.00
@ 2008-04-11 14:55 David Teigland
2008-04-13 11:56 ` Fabio M. Di Nitto
0 siblings, 1 reply; 4+ messages in thread
From: David Teigland @ 2008-04-11 14:55 UTC (permalink / raw
To: cluster-devel.redhat.com
A new source tarball of cluster code has been released: cluster-2.03.00
This has been taken from the STABLE2 branch in the cluster git tree. It
is compatible with the current stable release of openais (0.80.3), and the
current stable release of the kernel (2.6.24).
ftp://sources.redhat.com/pub/cluster/releases/cluster-2.03.00.tar.gz
To use gfs, a kernel patch is required to export three symbols from gfs2:
ftp://sources.redhat.com/pub/cluster/releases/lockproto-exports.patch
Abhijith Das (3):
gfs2_tool: remove 'gfs2_tool counters' as they aren't implemented anymore
gfs-kernel: fix for bz 429343 gfs_glock_is_locked_by_me assertion
gfs2_tool manpage: gfs2_tool counters doesn't exist anymore.
Andrew Price (1):
[[BUILD] Warn and continue if CONFIG_KERNELVERSION is not found
Bob Peterson (9):
Resolves: bz 435917: GFS2: mkfs.gfs2 default lock protocol
Resolves: bz 421761: 'gfs_tool lockdump' wrongly says 'unknown
Resolves: bz 431945: GFS: gfs-kernel should use device major:minor
Update to prior commit for bz431945: I forgot that STABLE2
Resolves: bz 436383: GFS filesystem size inconsistent
Fix savemeta so it saves gfs-1 rg information properly
Fix gfs2_edit print options (-p) to work properly for gfs-1
gfs2_edit was not recalculating the max block size after it figured
Fix some compiler warnings in gfs2_edit
Chris Feist (1):
Added back in change to description line to make chkconfig work properly.
Christine Caulfield (5):
[DLM] Don't segfault if lvbptr is NULL
[CMAN] Free up any queued messages when someone disconnects
[CMAN] Limit outstanding replies
[CMAN] valid port number & don't use it before validation
Remove references to broadcast.
David Teigland (4):
doc: update usage.txt
groupd: purge messages from dead nodes
dlm_tool: print correct rq mode in lockdump
libdlm: fix lvb copying
Fabio M. Di Nitto (8):
[BUILD] Fix configure script to handle releases
[BUILD] Fix build system with openais whitetank
[BUILD] Allow release version to contain padding 0's
Add toplevel .gitignore
[BUILD] Fix handling of version and libraries soname
[BUILD] Fix man page install permission
Revert "Fix help message to refer to script as 'fence_scsi_test'."
Revert "fix bz277781 by accepting "nodename" as a synonym for "node""
Joel Becker (1):
libdlm: Don't pass LKF_WAIT to the kernel
Jonathan Brassow (4):
rgmanager/lvm.sh: Fix bug 438816
rgmanager/lvm.sh: Fix bug bz242798
rgmanager/lvm.sh: change argument order of shell command
rgmanager/lvm.sh: Minor comment updates
Lon Hohberger (10):
Add Sybase failover agent
Update changelog
Add / fix Oracle 10g failover agent
[rgmanager] Make ip.sh check link states of non-ethernet devices
[rgmanager] Set cloexec bit in msg_socket.c
[rgmanager] Don't call quotaoff if quotas are not used
[CMAN] Fix "Node X is undead" loop bug
[rgmanager] Fix #432998
[cman] Apply missing fix for #315711
[CMAN] Make cman init script start qdiskd intelligently
Ryan McCabe (1):
fix bz277781 by accepting "nodename" as a synonym for "node"
Ryan O'Hara (15):
Variable should be quoted in conditional statement.
Fix unregister code to report failure correctly.
Remove "self" parameter. This was used to specify the name of the node
Fix code to use get_key subroutine.
Fix split calls to be consistent. Remove the optional LIMIT parameter.
Replace /var/lock/subsys/${0##*/} with /var/lock/subsys/scsi_reserve.
Fix success/failure reporting when registering devices at startup.
Rewrite of get_scsi_devices function.
Record devices that are successfully registered to /var/run/scsi_reserve.
Allow 'stop' to release the reservation if and only if there are no other
Attempt to register the node in the case where it must perform fence_scsi
Fix help message to refer to script as 'fence_scsi_test'.
BZ 248715
BZ: 373491, 373511, 373531, 373541, 373571, 429033
BZ 441323 : Redirect stderr to /dev/null when getting list of devices.
.gitignore | 1 +
cman/daemon/Makefile | 3 +-
cman/daemon/cmanccs.c | 11 +-
cman/daemon/cnxman-private.h | 2 +-
cman/daemon/commands.c | 2 +-
cman/daemon/daemon.c | 40 ++-
cman/daemon/daemon.h | 3 +-
cman/init.d/cman.in | 32 ++
cman/init.d/qdiskd | 21 +-
cman/lib/Makefile | 14 +-
cman/man/cman_tool.8 | 20 +-
cman/qdisk/main.c | 34 +-
configure | 87 +++-
dlm/lib/Makefile | 26 +-
dlm/lib/libdlm.c | 15 +-
dlm/tool/main.c | 8 +-
doc/usage.txt | 87 ++---
fence/agents/scsi/fence_scsi.pl | 248 ++++++++--
fence/agents/scsi/fence_scsi_test.pl | 171 ++++---
fence/agents/scsi/scsi_reserve | 300 ++++++++----
gfs-kernel/src/gfs/glock.h | 15 +-
gfs-kernel/src/gfs/ops_address.c | 29 +-
gfs-kernel/src/gfs/proc.c | 9 +-
gfs/gfs_grow/main.c | 4 +-
gfs/gfs_tool/util.c | 64 +--
gfs2/edit/gfs2hex.c | 12 +-
gfs2/edit/hexedit.c | 178 ++++++--
gfs2/edit/hexedit.h | 32 ++
gfs2/edit/savemeta.c | 38 +-
gfs2/man/gfs2_tool.8 | 4 -
gfs2/man/mkfs.gfs2.8 | 6 +-
gfs2/tool/Makefile | 3 +-
gfs2/tool/counters.c | 203 --------
gfs2/tool/main.c | 5 -
group/daemon/app.c | 25 +
group/daemon/cpg.c | 1 +
group/daemon/gd_internal.h | 1 +
group/dlm_controld/member_cman.c | 8 +
make/defines.mk.input | 1 +
make/man.mk | 2 +-
rgmanager/ChangeLog | 4 +
rgmanager/src/clulib/msg_socket.c | 12 +
rgmanager/src/daemons/restree.c | 2 +-
rgmanager/src/resources/ASEHAagent.sh | 893 +++++++++++++++++++++++++++++++++
rgmanager/src/resources/Makefile | 3 +-
rgmanager/src/resources/fs.sh | 51 ++-
rgmanager/src/resources/ip.sh | 18 +-
rgmanager/src/resources/lvm.metadata | 13 +-
rgmanager/src/resources/lvm.sh | 14 +-
rgmanager/src/resources/lvm_by_lv.sh | 15 +-
rgmanager/src/resources/lvm_by_vg.sh | 22 +-
rgmanager/src/resources/oracleas | 792 -----------------------------
rgmanager/src/resources/oracledb.sh | 869 ++++++++++++++++++++++++++++++++
53 files changed, 2954 insertions(+), 1519 deletions(-)
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Cluster-devel] cluster-2.03.00
2008-04-11 14:55 [Cluster-devel] cluster-2.03.00 David Teigland
@ 2008-04-13 11:56 ` Fabio M. Di Nitto
2008-04-14 16:13 ` David Teigland
0 siblings, 1 reply; 4+ messages in thread
From: Fabio M. Di Nitto @ 2008-04-13 11:56 UTC (permalink / raw
To: cluster-devel.redhat.com
On Fri, 11 Apr 2008, David Teigland wrote:
> A new source tarball of cluster code has been released: cluster-2.03.00
> This has been taken from the STABLE2 branch in the cluster git tree. It
> is compatible with the current stable release of openais (0.80.3), and the
> current stable release of the kernel (2.6.24).
>
> ftp://sources.redhat.com/pub/cluster/releases/cluster-2.03.00.tar.gz
>
Hi David,
I think I either misunderstood the versioning system or I missed something
along the way.
My understanding was that STABLE2 release would have had version 2.02.xx
where xx is incremental per release and a stable SONAME set to 2.2.
Snapshots from master would have taken 2.99.xx and kept an unstable API
set for commodity to 2.9.
I really don't think we should change the SONAME unless there is a need
for it.
Fabio
--
I'm going to make him an offer he can't refuse.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Cluster-devel] cluster-2.03.00
2008-04-13 11:56 ` Fabio M. Di Nitto
@ 2008-04-14 16:13 ` David Teigland
2008-04-14 16:53 ` Fabio M. Di Nitto
0 siblings, 1 reply; 4+ messages in thread
From: David Teigland @ 2008-04-14 16:13 UTC (permalink / raw
To: cluster-devel.redhat.com
On Sun, Apr 13, 2008 at 01:56:12PM +0200, Fabio M. Di Nitto wrote:
> On Fri, 11 Apr 2008, David Teigland wrote:
>
> >A new source tarball of cluster code has been released: cluster-2.03.00
> >This has been taken from the STABLE2 branch in the cluster git tree. It
> >is compatible with the current stable release of openais (0.80.3), and the
> >current stable release of the kernel (2.6.24).
> >
> > ftp://sources.redhat.com/pub/cluster/releases/cluster-2.03.00.tar.gz
> >
>
> Hi David,
>
> I think I either misunderstood the versioning system or I missed something
> along the way.
>
> My understanding was that STABLE2 release would have had version 2.02.xx
> where xx is incremental per release and a stable SONAME set to 2.2.
>
> Snapshots from master would have taken 2.99.xx and kept an unstable API
> set for commodity to 2.9.
>
> I really don't think we should change the SONAME unless there is a need
> for it.
I never had a clear plan for when we'd increment the middle number vs when
we'd increment the last number; we've always incremented the middle number
in the handful of past releases. I've also never understood how .so
naming should be done. Should .so numbers even be associated with the
cluster release numbers? What does the release number really "mean"; what
is it useful for? Similar question for .so numbers, what do they mean,
when should they change, when shouldn't they change? Since you have a far
better understanding in this area than I do (and you're the one who
actually implements it :-), could you define the rules for us for how this
all works? I don't have any preferences in the matter; I'm open to
whatever you come up with.
Dave
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Cluster-devel] cluster-2.03.00
2008-04-14 16:13 ` David Teigland
@ 2008-04-14 16:53 ` Fabio M. Di Nitto
0 siblings, 0 replies; 4+ messages in thread
From: Fabio M. Di Nitto @ 2008-04-14 16:53 UTC (permalink / raw
To: cluster-devel.redhat.com
On Mon, 14 Apr 2008, David Teigland wrote:
> On Sun, Apr 13, 2008 at 01:56:12PM +0200, Fabio M. Di Nitto wrote:
>> On Fri, 11 Apr 2008, David Teigland wrote:
>>
>>> A new source tarball of cluster code has been released: cluster-2.03.00
>>> This has been taken from the STABLE2 branch in the cluster git tree. It
>>> is compatible with the current stable release of openais (0.80.3), and the
>>> current stable release of the kernel (2.6.24).
>>>
>>> ftp://sources.redhat.com/pub/cluster/releases/cluster-2.03.00.tar.gz
>>>
>>
>> Hi David,
>>
>> I think I either misunderstood the versioning system or I missed something
>> along the way.
>>
>> My understanding was that STABLE2 release would have had version 2.02.xx
>> where xx is incremental per release and a stable SONAME set to 2.2.
>>
>> Snapshots from master would have taken 2.99.xx and kept an unstable API
>> set for commodity to 2.9.
>>
>> I really don't think we should change the SONAME unless there is a need
>> for it.
>
> I never had a clear plan for when we'd increment the middle number vs when
> we'd increment the last number; we've always incremented the middle number
> in the handful of past releases.
Ok... i understand where this is coming from.
> I've also never understood how .so
> naming should be done. Should .so numbers even be associated with the
> cluster release numbers?
Partially yes.
I always used this guide to the debian library packaging here:
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
It's a bit harsh language towards upstream but it explains all details on
how SONAME's should be handled and it's a short reading for upstreams.
> Similar question for .so numbers, what do they mean,
> when should they change, when shouldn't they change?
The soname reflects API and ABI of the shared library and they should be
changed according to the guide I mentioned above.
Now we are more or less in this situation:
cluster1/RHEL4 branches are shipping libraries with soname set to 1.0
RHEL5 is shipping soname 2.0
stable2 should have 2.2 (2.3 now is fine since we had one release out with
that number and it's no point to roll back and confuse users) as some
libraries did change.
stable3/RHEL6 will probably have major libraries changes and even if they
might be ABI compatible with the old ones, it's still safe to bump the
soname to 3.0.
The relation ship between soname and version is not always one to one, but
generally the release version gives an indication of the soname and not
the other way around IME.
The two can desync tho. Perhaps at some point we will release a cluster4
with soname 5... who knows.. so far we have been good and lucky enough to
keep those in sync.
As far I am concerned i do not care too much about master respecting the
SONAME rules as long as we make clear to our users that API and ABI can
change (hence using a 2.9 version that indicates an upcoming bump to 3.0).
For stable releases instead we need to be very accurate (or try our best
to be) in handling those bits.
For instance clvm or anything that use a shared library will need a
rebuild if we change soname, and we don't want to force those rebuild
without a reason (see linking section).
> What does the release number really "mean"; what
> is it useful for?
For us it's an easy way to identify what version a user is running as it
shows virtually everywhere from cman_tool to rgmanager --version or
equivalent.
> Since you have a far
> better understanding in this area than I do (and you're the one who
> actually implements it :-), could you define the rules for us for how this
> all works? I don't have any preferences in the matter; I'm open to
> whatever you come up with.
So what i think it's good for us is to:
- release stable2 now with version 2.03.xx and increment xx on each
release
- set the soname to 2.3 from now on unless there is a need to bump it.
- we can, at our discrection, change the version to 2.04.xx if there are
general intrusive changes or major stability updates (just an idea).
- release master with version 2.99.xx and increment xx on each release.
- set the soname to 2.9 and ready to bump it to 3.0 when we branch
stable3/rhel6.
the older RHEL5* releases will be released according to whatever you are
used to.
I am open to any other suggestions or ideas tho :)
Fabio
--
I'm going to make him an offer he can't refuse.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-04-14 16:53 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-11 14:55 [Cluster-devel] cluster-2.03.00 David Teigland
2008-04-13 11:56 ` Fabio M. Di Nitto
2008-04-14 16:13 ` David Teigland
2008-04-14 16:53 ` Fabio M. Di Nitto
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.