Bug 1199563

Summary: mount in a different namespace
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: hchen
Component: fuseAssignee: Bug Updates Notification Mailing List <rhs-bugs>
Status: CLOSED WONTFIX QA Contact: storage-qa-internal <storage-qa-internal>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: atumball, chrisw, csaba, nlevinki
Target Milestone: ---Keywords: ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-02 14:16:08 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: 1199554    
Bug Blocks:    

Description hchen 2015-03-06 15:57:07 UTC 
Description of problem:

Currently we have a problem with executing mount from one namespace to affect a different namespace.

The use case we are working towards is to allow a container application like gluster/cephs/nfs-utils to be run within a container in its own namespace.  Then allow the mount command to mount file systems in the hosts (primary) mnt namespaces.  

We would like to see a command like

mount --namespace=/proc/$n/ns/mnt

The critical point here is that the mount command would have to load all of its libraries and potentially helper routines before switching namespace.

An implementation of calling setns(2) in util-linux can be found at 
https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2015-February/msg00064.html

A validation of calling setns(2) in mount.glusterfs  can be found in the prototype at https://github.com/rootfs/install-glusterfs-on-fc21/. The test description can be found in the README.md file.

Version-Release number of selected component (if applicable):


How reproducible:

NA

Steps to Reproduce:
1.
2.
3.

Actual results:

NA
Expected results:
NA

Additional info:
Comment 4 Amar Tumballi 2018-04-02 14:16:08 UTC 
We now have CNS done for any container workloads, and there is no current focus on fixing this issue. Please reopen the bug if CNS (Container Native Storage doesn't solve the issue for you.