Bug 798169

Summary:	Volume set "auth.allow/auth.reject" should re initiate the client connection
Product:	[Community] GlusterFS	Reporter:	Shwetha Panduranga <shwetha.h.panduranga>
Component:	cli	Assignee:	Rajesh <rajesh>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	mainline	CC:	gluster-bugs, vagarwal, vbellur
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-03-15 10:40:03 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	DP	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Shwetha Panduranga 2012-02-28 08:34:11 UTC

Description of problem:
create a volume with auth.allow set to <ip_address/subnet> of client nodes. Perform I/O operations from the mounts on client nodes. set auth.reject <ip_address/subnet> for same client nodes. 

Since the client has mounted to volume before the auth.reject option is set, client nodes are still able to access data and perform operations on data from the mount points. 
  
Ideally, the auth.reject or auth.allow volume set operations should re establish the client connections.

Comment 1 Rajesh 2012-03-15 10:40:03 UTC

This is the expected behavior. Antecedent connections should not be reset.

Comment 2 Shwetha Panduranga 2012-04-09 15:57:27 UTC

This bug has to be documented.