On Mon, Dec 23, 2013 at 7:04 AM, Flavio Percoco <fla...@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 <fla...@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 <jaypi...@gmail.com >>>>> <mailto:jaypi...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
