Open Stack

On 23/12/13 22:46 +0800, Zhi Yan Liu wrote:
>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.

I don't like the idea of having it in the client. I'd prefer the
client to just consume it.

IMHO, glance.store sounds like the way to go here.

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


mhh, not sure. That sounds like way more of what the lib should do.
IMHO, this lib shouldn't take care of any admin operation, it should
be just about getting / putting data into those stores.

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131223/b07adcd2/attachment.pgp>