[gpfsug-discuss] OpenStack Manila Driver

[Simon Thompson (Research Computing - IT Services)]

I didn;t think that the *current* Manilla driver user GPFS protocol, but
sat on top of Ganesha server.

Simon

On 16/06/2015 09:41, "Adam Huffman" <adam.huffman at crick.ac.uk> wrote:

>
>The presentation of shared storage by Manila isn’t necessarily via NFS.
>Some of the drivers, I believe the GPFS one amongst them, allow some form
>of native connection either via the guest or via a VirtFS connection to
>the client on the hypervisor.
>
>Best Wishes,
>Adam
>
>
>—
>
>
>
>
>
>> On 16 Jun 2015, at 08:36, Luke Raimbach <Luke.Raimbach at crick.ac.uk>
>>wrote:
>>
>> So as I understand things, Manila is an OpenStack component which
>>allows tenants to create and destroy shares for their instances which
>>would be accessed over NFS. Perhaps I’ve not done enough research in to
>>this though – I’m also not an OpenStack expert.
>>
>> The tenants don’t have root access to the file system, but the Manila
>>component must act as a wrapper to file system administrative
>>equivalents like mmcrfileset, mmdelfileset, link and unlink. The shares
>>are created as GPFS filesets which are then presented over NFS.
>>
>> The unlinking of the fileset worries me for the reasons stated
>>previously.
>>
>> From: gpfsug-discuss-bounces at gpfsug.org
>>[mailto:gpfsug-discuss-bounces at gpfsug.org] On Behalf Of Wahl, Edward
>> Sent: 15 June 2015 15:00
>> To: gpfsug main discussion list
>> Subject: Re: [gpfsug-discuss] OpenStack Manila Driver
>>
>> 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
>> W: 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.
>> 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.
>> _______________________________________________
>> gpfsug-discuss mailing list
>> gpfsug-discuss at gpfsug.org
>> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
>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.
>_______________________________________________
>gpfsug-discuss mailing list
>gpfsug-discuss at gpfsug.org
>http://gpfsug.org/mailman/listinfo/gpfsug-discuss