Open Stack

> Message: 2
> Date: Sat, 23 Feb 2013 17:22:16 +0000
> From: Mark McLoughlin <markmc at redhat.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Filesystem as a Service API in Cinder
>         [was Management of NAS (NFS/CIFS shares) in OpenStack]
> Message-ID: <1361640136.27021.14.camel at sorcha>
> Content-Type: text/plain; charset="UTF-8"
> 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.

There was a bit of discussion at the time, which covered the concern you
re-raised below.

> Firstly, I think this is awesome - it's a really interesting new feature
> and I'd love OpenStack to support it.

That seems to be well understood and agreed. The problem seems to be lack
of anyone willing/able to lead a separate project around this.

> 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?

I agree to a certain extent, but this can be looked at from a number of
angles... For one thing, object storage really IS different to the others,
it's storage for the Interwebs and I would argue that it isn't a core
ingredient in IaaS. Block and file/share based storage are both about
programmatic attach/detach of data sources/syncs to/from instances (or more
generally, managed compute infrastructure), and mainly LAN based.

> 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.

I think the few of us that responded to this following the Grizzly summit
were hopeful that integration with Cinder would expedite getting the
feature into the wild, with the knowledge that it might be excised into a
separate project later. I guess it will be discussed yet again at the
Havana summit...

--
Cheers,
~Blairo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130227/d3a67b90/attachment.html>