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.


--
@flaper87
Flavio Percoco

Attachment: pgpc0yiev4T5j.pgp
Description: PGP signature

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to