Description of problem: Some log files (e.g)/var/log/glusterfs/*-rebalance.log contains the lines, which says "Using GlusterFS 3.3", eventhough RHS2.1 uses GlusterFS3.4" Sample Lines from Log file ========================== <snip> [2013-04-25 12:31:09.902748] I [client-handshake.c:1658:select_server_supported_programs] 0-dr-vmstore-client-0: Using Program GlusterFS 3.3, Num (1298437), Version (330) [2013-04-25 12:31:09.902872] I [client-handshake.c:1658:select_server_supported_programs] 0-dr-vmstore-client-3: Using Program GlusterFS 3.3, Num (1298437), Version (330) [2013-04-25 12:31:09.903028] I [client-handshake.c:1658:select_server_supported_programs] 0-dr-vmstore-client-2: Using Program GlusterFS 3.3, Num (1298437), Version (330) [2013-04-25 12:31:09.903221] I [client-handshake.c:1658:select_server_supported_programs] 0-dr-vmstore-client-1: Using Program GlusterFS 3.3, Num (1298437), Version (330) [2013-04-25 12:31:09.903312] I [client-handshake.c:1658:select_server_supported_programs] 0-dr-vmstore-client-6: Using Program GlusterFS 3.3, Num (1298437), Version (330) [2013-04-25 12:31:09.903439] I [client-handshake.c:1658:select_server_supported_programs] 0-dr-vmstore-client-4: Using Program GlusterFS 3.3, Num (1298437), Version (330) [2013-04-25 12:31:09.903538] I [client-handshake.c:1658:select_server_supported_programs] 0-dr-vmstore-client-5: Using Program GlusterFS 3.3, Num (1298437), Version (330) </snip> Version-Release number of selected component (if applicable): RHS2.1 - glusterfs-3.4.0.1rhs-1.el6rhs How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: "GlusterFS 3.4" tag should be used in log files Expected results: "GlusterFS 3.3" tag/word is used in log files Additional info:
Ok, now figured out. These are the 'protocol' versions, which doesn't change between every releases. We look at version by below line: [2013-03-20 00:51:58.623810] I [glusterfsd.c:1776:main] 0-/usr/local/sbin/glusterfs: Started running /usr/local/sbin/glusterfs version 3.4.0.1rhs (/usr/local/sbin/glusterfs -s localhost --volfile-id gluster/glustershd -p /var/lib/glusterd/glustershd/run/glustershd.pid -l /usr/local/var/log/glusterfs/glustershd.log -S /var/run/04bfab366eda4f34d19af2461686512f.socket --xlator-option *replicate*.node-uuid=8a48b8ae-088f-40ef-a2d8-949cfa360f39) The current log you specified is by design. We can rather have it as an knowledge base article or something.
This is highly misleading, and concerning. There are bugs listed against gluster which can cause data loss for example, when old version clients connect during rebalance operations etc. For this reason it is important to be able to spot old clients connecting in logs. This is a bug, and logs should be amended so it is clear that they refer to a protocol number, not a gluster version number.
Still seeing this log entry in GlusterFS 3.8.6. Its realy confusing! When i saw this the first time i was thinking the updates to nex major version did not work correctly.
For God's sake, just reopen and fix this bug. Yes, we now know the version number refers to the protocol, not the client version number. However, the messages are misleading. Please show some respect for your users, and stop misleading them with bad log messages.
(In reply to BugMasta from comment #5) > For God's sake, just reopen and fix this bug. > > Yes, we now know the version number refers to the protocol, not the client > version number. However, the messages are misleading. > > Please show some respect for your users, and stop misleading them with bad > log messages. Hi, Could you please open up upstream bz with Gluster ?( https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS ) This issue could be certainly taken care. Thanks for pointing this out.
Done: https://bugzilla.redhat.com/show_bug.cgi?id=1399158
Many thanks to yous guise, Andre and Satheesaran. It's not a critical bug fix, but it will save users some gnashing of teeth. The last thing you need when investigating a problem is to come across misleading messages like these. They can really lead you down some blind alleys and cause grief. So thanks for taking ownership of this issue and getting onto it. I'm a grumpy bastard a lot of the time, but when something is handled properly, I'm happy to say thanks :-)
(In reply to BugMasta from comment #8) > Many thanks to yous guise, Andre and Satheesaran. > > It's not a critical bug fix, but it will save users some gnashing of teeth. > The last thing you need when investigating a problem is to come across > misleading messages like these. They can really lead you down some blind > alleys and cause grief. So thanks for taking ownership of this issue and > getting onto it. > > I'm a grumpy bastard a lot of the time, but when something is handled > properly, I'm happy to say thanks :-) Yes, we can understand the motivation. We will address the issue soon. Thanks for raising your concern.