Bug 858419

Summary:	A node that was offline is not getting volume changes applied to it when it rejoins the cluster
Product:	[Red Hat Storage] Red Hat Gluster Storage	Reporter:	Scott Haines <shaines>
Component:	glusterd	Assignee:	krishnan parthasarathi <kparthas>
Status:	CLOSED WORKSFORME	QA Contact:	Sudhir D <sdharane>
Severity:	high	Docs Contact:
Priority:	high
Version:	2.0	CC:	amarts, asriram, gluster-bugs, nsathyan, puebele, rhs-bugs, vbellur
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Known Issue
Doc Text:	A volume deleted in the absence of one of the peers wouldn't be removed from the cluster's list of volumes. This is because the 'import' logic of peers that rejoin the cluster is not capable of differentiating between volumes deleted and volumes added in the absence of the other (conflicting) peers. For now, we intend to manually detect it which may involve analysing cli cmd logs to get the cluster view of the volumes that 'ought' to be present. Once we arrive at this picture, we could use volume-sync to reconcile the skewed view of volumes in the cluster. Bricks added/deleted to a volume while some of the peers were down/unreachable, are 'imported' as they rejoin the cluster.	Story Points:	---
Clone Of:	839213	Environment:
Last Closed:	2012-12-20 05:54:06 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	839213
Bug Blocks:

Comment 2 Amar Tumballi 2012-12-11 11:28:17 UTC

source bug updated with comments, and known issue section. Need to understand if thats enough as the fix.

---
A volume deleted in the absence of one of the peers wouldn't be removed from the cluster's list of volumes. This is because the 'import' logic of peers that rejoin the cluster is not capable of differentiating between volumes deleted and volumes added in the absence of the other (conflicting) peers.

For now, we intend to manually detect it which may involve analysing cli cmd logs to get the cluster view of the volumes that 'ought' to be present. Once we arrive at this picture, we could use volume-sync to reconcile the skewed view of volumes in the cluster.

Bricks added/deleted to a volume while some of the peers were down/unreachable, are 'imported' as they rejoin the cluster. This works fine on upstream/master.
---