Bug 858419 - A node that was offline is not getting volume changes applied to it when it rejoins the cluster
A node that was offline is not getting volume changes applied to it when it r...
Status: CLOSED WORKSFORME
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: glusterd (Show other bugs)
2.0
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: krishnan parthasarathi
Sudhir D
:
Depends On: 839213
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-18 18:19 EDT by Scott Haines
Modified: 2015-11-03 18:04 EST (History)
7 users (show)

See Also:
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 00:54:06 EST
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)
Comment 2 Amar Tumballi 2012-12-11 06:28:17 EST
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.
---

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