Open Stack

On Mon, Dec 23, 2013 at 7:04 AM, Flavio Percoco <flavio at redhat.com> wrote:

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

+1, not sure if I cause some confusion, but what you said directly above is
exactly what I meant.


>
> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131224/aa5d4aeb/attachment.html>