[gpfsug-discuss] OpenStack Manila Driver

Wahl, Edward ewahl at osc.edu
Mon Jun 15 14:59:44 BST 2015


Perhaps I misunderstand here, but if the tenants have administrative (ie:root) privileges to the underlying file system management commands I think mmunlinkfileset might be a minor concern here.  There are FAR more destructive things that could occur.

I am not an OpenStack expert and I've not even looked at anything past Kilo,  but my understanding was that these commands were not necessary for tenants.  They access a virtual block device that backs to GPFS, correct?

Ed Wahl
OSC

________________________________


++
From: gpfsug-discuss-bounces at gpfsug.org [gpfsug-discuss-bounces at gpfsug.org] on behalf of Luke Raimbach [Luke.Raimbach at crick.ac.uk]
Sent: Monday, June 15, 2015 4:35 AM
To: gpfsug-discuss at gpfsug.org
Subject: [gpfsug-discuss] OpenStack Manila Driver


Dear All,



We are looking forward to using the manila driver for auto-provisioning of file shares using GPFS. However, I have some concerns...



Manila  presumably gives tenant users access to file system commands like mmlinkfileset and mmunlinkfileset. Given that mmunlinkfileset quiesces the file system, there is potentially an impact from one tenant on another - i.e. someone unlinking and deleting a lot of filesets during a tenancy cleanup might cause a cluster pause long enough to trigger other failure events or even start evicting nodes. You can see why this would be bad in a cloud environment.




Has this scenario been addressed at all?



Cheers,

Luke.


Luke Raimbach​
Senior HPC Data and Storage Systems Engineer
The Francis Crick Institute
Gibbs Building
215 Euston Road
London NW1 2BE

E: luke.raimbach at crick.ac.uk<mailto:luke.raimbach at crick.ac.uk>
W: www.crick.ac.uk<http://www.crick.ac.uk/>


The Francis Crick Institute Limited is a registered charity in England and Wales no. 1140062 and a company registered in England and Wales no. 06885462, with its registered office at 215 Euston Road, London NW1 2BE.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20150615/2117b55d/attachment.htm>


More information about the gpfsug-discuss mailing list