Bug 829042

Summary: [FEAT] selective read-only mode
Product: [Community] GlusterFS Reporter: Csaba Henk <csaba>
Component: unclassifiedAssignee: Saravanakumar <sarumuga>
Status: CLOSED DUPLICATE QA Contact:
Severity: unspecified Docs Contact:
Priority: low    
Version: mainlineCC: gluster-bugs, vagarwal
Target Milestone: ---Keywords: FutureFeature, Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 1265574 (view as bug list) Environment:
Last Closed: 2015-10-23 06:24:09 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:    
Bug Blocks: 1265574, 1302203    

Description Csaba Henk 2012-06-05 20:24:02 UTC
Description of problem:

Read-only has already been integrated to the volume set framework so we can enforce read-only operation to a given volume (ie. all mounts of it will be read-only). However, we need to fine-tune this feature so that read-only / writable behavior shall be chosen according to the context of the client access, ie. whether it's normal or internal maintenance mount, and within latter, the type of maintenance access (eg. geo-replication, rebalance, etc.).

The feature should be general -- so, if say glusterfs knows of N contexts, which are (according to the current convention) represented as -1, -2, ..., -N values for client-pid (and non-negative client-pids mean normal access, ie. it corresponds to the actual pid the request came from [0 for kernel]), (the union of) any set of the {|x| x >= 0}, -1, -2,..., -N value ranges should be possible to specify as the ones where read-only access is enforced.

Comment 2 Kaleb KEITHLEY 2015-10-22 15:46:38 UTC
because of the large number of bugs filed against mainline version\ is ambiguous and about to be removed as a choice.

If you believe this is still a bug, please change the status back to NEW and choose the appropriate, applicable version for it.

Comment 3 Saravanakumar 2015-10-23 05:58:19 UTC
moving back to NEW, as this is a required feature.

Comment 4 Vivek Agarwal 2015-10-23 06:24:09 UTC

*** This bug has been marked as a duplicate of bug 1265574 ***