Bug 1279681 - [Tier]: Peer probe happened with nodes having same volume name with diff vol type.
[Tier]: Peer probe happened with nodes having same volume name with diff vol ...
Status: MODIFIED
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: tier (Show other bugs)
3.1
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: hari gowtham
nchilaka
tier-glusterd
: Reopened, ZStream
Depends On: 1287992
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-09 22:08 EST by Byreddy
Modified: 2018-01-29 16:28 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-24 03:19:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Byreddy 2015-11-09 22:08:31 EST
Description of problem:
=======================
Peer probe is happened  b/w the rhgs nodes which are having same volume name in which one node volume is normal volume and other node volume is Tiered volume

and after peer probe success, normal volume bricks are killed and tiered volume displayed in the cluster.

Version-Release number of selected component (if applicable):
=============================================================
glusterfs-3.7.5-5


How reproducible:
=================
100%


Steps to Reproduce:
===================
1. Have two nodes (node-1 and node-2) with rhgs 3.1.2(glusterfs-3.7.5-5)  //DON'T CREATE THE CLUSTER now
2. Create one normal volume in node-1 with vol name Dis ( Eg: Distributed vol type )
3. Create one tiered volume in node-2 with vol name Dis.
4. Make a note of PIDs of bricks on both the nodes.
5. Peer probe node-2 from node-1 // it will success
6. Check volume status on both the nodes //will see Tiered volume on both the nodes
7. Now check the PIDs on both the nodes as step-4 // will see only tiered volume brick PIDs

Actual results:
===============
Peer probe happening with nodes having same volume name.


Expected results:
=================
Peer probe should not happen with nodes having same volume name.


Additional info:
Comment 2 Byreddy 2015-11-09 22:26:55 EST
Additional Info:
================
You can peer probe from any one node in create a cluster, it not like the step-5 in reproducing steps, you need to peer probe from node-1 only.
Comment 4 Atin Mukherjee 2015-11-16 07:08:29 EST
The difference between distributed volume and a tiered volume is in terms of its version. Since a tier volume creation is a multi step process (create volume + attach tier) the version will be always +1 compared to a normal volume. In this case glusterd_compare_friend_volume() detects a version mismatch and hence initiates a update req from the other peer which results into overwriting the distributed volume with the tier volume. This could very well happen for a distributed vs distributed volume as well where the version of these volume differ.

This bug is caught as part of negative testing as probing a node with same volume name configured in not recommended, hence lowering the priority and severity.

This is a bug from Day 1 and the fix is not that straight forward. I'd suggest to defer it from 3.1.2
Comment 5 RHEL Product and Program Management 2015-11-16 07:56:05 EST
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.
Comment 8 hari gowtham 2016-02-17 07:01:31 EST
This situation is avoided from the addition of the following patch.

master : http://review.gluster.org/#/c/12864/

3.7 : http://review.gluster.org/#/c/12888/

peer probe to a node with an existing volume is avoided and as we wont be able to create two volumes with same name in a cluster. the above situation can not be reached. The patch will get in for 3.1.3 during rebase.
Comment 9 hari gowtham 2016-05-24 03:19:46 EDT
The way peer probe can be done has been changed, earlier it can be probed between two clusters and this created the issue.
The above mentioned patch prevents probing from one cluster to another cluster.
Now peer probe can be done from one cluster to a node which is not a part of any other cluster. Doing so we eliminate the chance of creating volumes with same volume name. as the issue was caused because we probed from one node have a volume name same as the volume name on the probed cluster.

The patch got in the 3.1.3 from the tag 3.7.9-1 

As the issue is resolved. i'm closing the bug. please feel free to open it if the problem exists after following the mentioned methods for prevention.
Comment 10 Rejy M Cyriac 2016-05-24 03:46:17 EDT
(In reply to hari gowtham from comment #9)
> The way peer probe can be done has been changed, earlier it can be probed
> between two clusters and this created the issue.
> The above mentioned patch prevents probing from one cluster to another
> cluster.
> Now peer probe can be done from one cluster to a node which is not a part of
> any other cluster. Doing so we eliminate the chance of creating volumes with
> same volume name. as the issue was caused because we probed from one node
> have a volume name same as the volume name on the probed cluster.
> 
> The patch got in the 3.1.3 from the tag 3.7.9-1 
> 
> As the issue is resolved. i'm closing the bug. please feel free to open it
> if the problem exists after following the mentioned methods for prevention.

I do not believe that this BZ can be CLOSED CURRENTRELEASE if the reported issue is still reproducible at the current RELEASED version, which is actually RHGS 3.1.2, and not RHGS 3.1.3.

The fix could be verified by QE either during the release cycle of RHGS 3.1.3, or post the GA of RHGS 3.1.3 since the BZ is not part of the approved list of bugs for the release.

Most importantly, the BZ needs to remain OPEN at least till the GA of RHGS 3.1.3 before it may be closed.
Comment 12 Milind Changire 2017-01-18 04:58:28 EST
Moving to MODIFIED.
Patch available downstream as commit 8a9a532.

Note You need to log in before you can comment on or make changes to this bug.