Open Stack

On Mon, Dec 23, 2013 at 10:26 PM, Flavio Percoco <flavio at redhat.com> wrote:
> On 23/12/13 09:00 -0500, Jay Pipes wrote:
>>
>> On 12/23/2013 08:48 AM, Mark Washenberger wrote:
>>>
>>>
>>>
>>>
>>> On Mon, Dec 23, 2013 at 4:57 AM, Jay Pipes <jaypipes at gmail.com
>>> <mailto:jaypipes at gmail.com>> wrote:
>>>
>>>    On 12/23/2013 05:42 AM, Thierry Carrez wrote:
>>>
>>>        Flavio Percoco wrote:
>>>
>>>            On 21/12/13 00:41 -0500, Jay Pipes wrote:
>>>
>>>                Cinder is for block storage. Images are just a bunch of
>>>                blocks, and
>>>                all the store drivers do is take a chunked stream of
>>>                input blocks and
>>>                store them to disk/swift/s3/rbd/toaster and stream those
>>>                blocks back
>>>                out again.
>>>
>>>                So, perhaps the most appropriate place for this is in
>>>                Cinder-land.
>>>
>>>
>>>            This is an interesting suggestion.
>>>
>>>            I wouldn't mind putting it there, although I still prefer it
>>>            to be
>>>            under glance for historical reasons and because Glance team
>>>            knows that
>>>            code.
>>>
>>>            How would it work if this lib falls under Block Storage
>>> program?
>>>
>>>            Should the glance team be added as core contributors of this
>>>            project?
>>>            or Just some of them interested in contributing / reviewing
>>>            those
>>>            patches?
>>>
>>>            Thanks for the suggestion. I'd like John and Mark to weigh
>>>            in too.
>>>
>>>
>>>        Programs are a team of people on a specific mission. If the
>>>        stores code
>>>        is maintained by a completely separate group (glance devs), then
>>> it
>>>        doesn't belong in the Block Storage program... unless the Cinder
>>>        devs
>>>        intend to adopt it over the long run (and therefore the
>>>        contributors of
>>>        the Block Storage program form a happy family rather than two
>>>        separate
>>>        groups).
>>>
>>>
>>>    Understood. The reason I offered this up as a suggestion is that
>>>    currently Cinder uses the Glance REST API to store and retrieve
>>>    volume snapshots, and it would be more efficient to just give Cinder
>>>    the ability to directly retrieve the blocks from one of the
>>>    underlying store drivers (same goes for Nova's use of Glance).
>>>    ...and, since the glance.store drivers are dealing with blocks, I
>>>    thought it made more sense in Cinder.
>>>
>>>
>>> True, Cinder and Nova should be talking more directly to the underlying
>>> stores--however their direct interface should probably be through
>>> glanceclient. (Glanceclient could evolve to use the glance.store code I
>>> imagine.)
>>
>>
>> Hmm, that is a very interesting suggestion. glanceclient containing the
>> store drivers. I like it. Will be a bit weird, though, having the
>> glanceclient call the Glance API server to get the storage location details,
>> which then calls the glanceclient code to store/retrieve the blocks :)
>
>
> Exactly. This is part of the original idea. Allow Glance, nova,
> glanceclient and cinder to interact with the store code.
>

Actually I consider this Glance store stuff can be packaged to a
dedicated common lib belongs to Glance, maybe we can put it into
glanceclient if we don't like create a new sub-lib, IMO it worked just
like current Cinder's brick lib IMO, in sort term.

In long term we can move those stuff all to oslo when they stable
enough (if we can see that day ;) ) and don't organize them by
project's POV but storage type: oslo.blockstore (or other name) for
block storage backend handling, and oslo.objectstore for object
storage, and upper layer project just delegate all real storage device
operation requests to those lib, like mount/attach, unmoun/detach,
read/write..

zhiyan

>
> --
> @flaper87
> Flavio Percoco
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>