<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 23, 2013 at 7:04 AM, Flavio Percoco <span dir="ltr"><<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 23/12/13 22:46 +0800, Zhi Yan Liu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Dec 23, 2013 at 10:26 PM, Flavio Percoco <<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 23/12/13 09:00 -0500, Jay Pipes wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 12/23/2013 08:48 AM, Mark Washenberger wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
<br>
On Mon, Dec 23, 2013 at 4:57 AM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a><br>
<mailto:<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>>> wrote:<br>
<br>
On 12/23/2013 05:42 AM, Thierry Carrez wrote:<br>
<br>
Flavio Percoco wrote:<br>
<br>
On 21/12/13 00:41 -0500, Jay Pipes wrote:<br>
<br>
Cinder is for block storage. Images are just a bunch of<br>
blocks, and<br>
all the store drivers do is take a chunked stream of<br>
input blocks and<br>
store them to disk/swift/s3/rbd/toaster and stream those<br>
blocks back<br>
out again.<br>
<br>
So, perhaps the most appropriate place for this is in<br>
Cinder-land.<br>
<br>
<br>
This is an interesting suggestion.<br>
<br>
I wouldn't mind putting it there, although I still prefer it<br>
to be<br>
under glance for historical reasons and because Glance team<br>
knows that<br>
code.<br>
<br>
How would it work if this lib falls under Block Storage<br>
program?<br>
<br>
Should the glance team be added as core contributors of this<br>
project?<br>
or Just some of them interested in contributing / reviewing<br>
those<br>
patches?<br>
<br>
Thanks for the suggestion. I'd like John and Mark to weigh<br>
in too.<br>
<br>
<br>
Programs are a team of people on a specific mission. If the<br>
stores code<br>
is maintained by a completely separate group (glance devs), then<br>
it<br>
doesn't belong in the Block Storage program... unless the Cinder<br>
devs<br>
intend to adopt it over the long run (and therefore the<br>
contributors of<br>
the Block Storage program form a happy family rather than two<br>
separate<br>
groups).<br>
<br>
<br>
Understood. The reason I offered this up as a suggestion is that<br>
currently Cinder uses the Glance REST API to store and retrieve<br>
volume snapshots, and it would be more efficient to just give Cinder<br>
the ability to directly retrieve the blocks from one of the<br>
underlying store drivers (same goes for Nova's use of Glance).<br>
...and, since the glance.store drivers are dealing with blocks, I<br>
thought it made more sense in Cinder.<br>
<br>
<br>
True, Cinder and Nova should be talking more directly to the underlying<br>
stores--however their direct interface should probably be through<br>
glanceclient. (Glanceclient could evolve to use the glance.store code I<br>
imagine.)<br>
</blockquote>
<br>
<br>
Hmm, that is a very interesting suggestion. glanceclient containing the<br>
store drivers. I like it. Will be a bit weird, though, having the<br>
glanceclient call the Glance API server to get the storage location details,<br>
which then calls the glanceclient code to store/retrieve the blocks :)<br>
</blockquote>
<br>
<br>
Exactly. This is part of the original idea. Allow Glance, nova,<br>
glanceclient and cinder to interact with the store code.<br>
<br>
</blockquote>
<br>
Actually I consider this Glance store stuff can be packaged to a<br>
dedicated common lib belongs to Glance, maybe we can put it into<br>
glanceclient if we don't like create a new sub-lib, IMO it worked just<br>
like current Cinder's brick lib IMO, in sort term.<br>
</blockquote>
<br></div></div>
I don't like the idea of having it in the client. I'd prefer the<br>
client to just consume it.<br></blockquote><div><br></div><div>+1, not sure if I cause some confusion, but what you said directly above is exactly what I meant.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
IMHO, glance.store sounds like the way to go here.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In long term we can move those stuff all to oslo when they stable<br>
enough (if we can see that day ;) ) and don't organize them by<br>
project's POV but storage type: oslo.blockstore (or other name) for<br>
block storage backend handling, and oslo.objectstore for object<br>
storage, and upper layer project just delegate all real storage device<br>
operation requests to those lib, like mount/attach, unmoun/detach,<br>
read/write..<br>
</blockquote>
<br>
<br></div>
mhh, not sure. That sounds like way more of what the lib should do.<br>
IMHO, this lib shouldn't take care of any admin operation, it should<br>
be just about getting / putting data into those stores.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
@flaper87<br>
Flavio Percoco<br>
</font></span><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>