[openstack-dev] Filesystem as a Service API in Cinder [was Management of NAS (NFS/CIFS shares) in OpenStack]

John Garbutt john at johngarbutt.com
Mon Feb 25 09:57:16 UTC 2013


+1

I like the ability to orchestrate file shares for users. That sounds useful.

However, it sounds very different to attaching disks to VMs. Indeed
you seem to call the API from a very different place. Sounds like it
should be a separate API. To me it sounds as different as object
storage.

I could imagine cloud-init having a plugin that attaches assigned file
shares on boot. It would seem wrong to give cloud-init access to the
rest of Cinder, just doesn't make sense.

John

On 23 February 2013 17:22, Mark McLoughlin <markmc at redhat.com> wrote:
> Hi,
>
> On Wed, 2012-11-21 at 15:52 +0000, Swartzlander, Ben wrote:
>> NetApp is interested in providing a common way to provision and attach
>> NFS and CIFS shares to VMs in an OpenStack environment. We presented our
>> ideas at the OpenStack summit last month and we have submitted a patch
>> to Cinder that demonstrates one way to implement these features. We
>> believe that extensions to the Cinder API are the most logical and least
>> disruptive way to bring these features to OpenStack, but discussions at
>> the conference show there are differences of opinion on this topic.
>>
>> I would like to invite anyone who is interested in NFS and CIFS in
>> OpenStack, or Cinder or NAS in general to take a look at our etherpad
>> and our code submission and provide feedback and suggestions.
>>
>> Etherpad: https://etherpad.openstack.org/cinder-nas-extensions
>> Gerrit Submission: https://review.openstack.org/#/c/16054/
>>
>> Our proposed patch does include substantial changes and we want to do
>> our best to ensure that we do it right the first time, so please reply
>> to me and/or this thread if you're interested and have good ideas,
>> opinions, or suggestions. We also welcome any code review comments on
>> the gerrit submission.
>
> I must admit this discussion completely escaped my attention. There
> wasn't much feedback on the original thread, so I'm re-titling to make
> it more obvious what's being proposed here.
>
> The blueprint is:
>
>   https://blueprints.launchpad.net/cinder/+spec/cinder-protocol-enhancements
>
> and latest review:
>
>   https://review.openstack.org/21290
>
> and wiki pages:
>
>   https://wiki.openstack.org/wiki/CinderProtocolEnhancements
>   https://wiki.openstack.org/wiki/CinderProtocolEnhancementsAPI
>
> with the usage looking like:
>
>   $> cinder share-create cifs 10
>   $> cinder share-list
>   $> cinder share-allow ip 10.0.1.*
>   $> cinder share-delete d596078a-7bfb-4977-b10d-2cf5528e708d
>
> The share-show command would give e.g.
>
>   export_location = //172.18.194.81/volume-adcc79e4-336c-4ad2-9d38-2b65d062d971
>
> and you'd use this from within your instance to mount the share.
>
> Firstly, I think this is awesome - it's a really interesting new feature
> and I'd love OpenStack to support it.
>
> However ... looking at the concept, the API and the implementation it
> really seems to me that there's no reason to include this in Cinder.
>
> The concept of filesystem storage is as distinct from block storage as
> object storage is from block storage. The blueprint says:
>
>    We propose and intend to act to evolve Cinder as the canonical
>    storage provisioning control plane in OpenStack independent of
>    storage protocol type (whether block or file)
>
> but I don't get it ... why does conceptually make sense? Why block and
> file? Why not object too?
>
> The API has been added to the OpenStack Volumes API as extensions, but
> it really should be a completely new Shares API.
>
> The implementation of the shares support is completely separate from
> Cinder's volumes support.
>
> The only benefit to adding this to Cinder AFAICS is that we avoid having
> another copy of Nova's API infrastructure and scheduling code. Honestly,
> if that was something we felt outweighed other concerns ... then we
> shouldn't have split Cinder out from Nova in the first place. The way I
> see it, another copy of this code will encourage people to double down
> on sharing the code via Oslo.
>
> Cheers,
> Mark.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list