Open Stack

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.