<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 22, 2014 at 7:33 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"><span class="">On 10/22/2014 02:30 PM, Zhi Yan Liu wrote:<br>
> Greetings,<br>
><br>
> On Wed, Oct 22, 2014 at 4:56 PM, Flavio Percoco <<a href="mailto:flavio@redhat.com">flavio@redhat.com</a>> wrote:<br>
>> Greetings,<br>
>><br>
>> Back in Havana a, partially-implemented[0][1], Cinder driver was merged<br>
>> in Glance to provide an easier and hopefully more consistent interaction<br>
>> between glance, cinder and nova when it comes to manage volume images<br>
>> and booting from volumes.<br>
><br>
> With my idea, it not only for VM provisioning and consuming feature<br>
> but also for implementing a consistent and unified block storage<br>
> backend for image store.  For historical reasons, we have implemented<br>
> a lot of duplicated block storage drivers between glance and cinder,<br>
> IMO, cinder could regard as a full-functional block storage backend<br>
> from OpenStack's perspective (I mean it contains both data and control<br>
> plane), glance could just leverage cinder as a unified block storage<br>
> backend. Essentially, Glance has two kind of drivers, block storage<br>
> driver and object storage driver (e.g. swift and s3 driver),  from<br>
> above opinion, I consider to give glance a cinder driver is very<br>
> sensible, it could provide a unified and consistent way to access<br>
> different kind of block backend instead of implement duplicated<br>
> drivers in both projects.<br>
<br>
</span>Let me see if I got this right. You're suggesting to have a cinder<br>
driver in Glance so we can basically remove the<br>
'create-volume-from-image' functionality from Cinder. is this right?<br>
<span class=""><br>
> I see some people like to see implementing similar drivers in<br>
> different projects again and again, but at least I think this is a<br>
> hurtless and beneficial feature/driver.<br>
<br>
</span>It's not as harmless as it seems. There are many users confused as to<br>
what the use case of this driver is. For example, should users create<br>
volumes from images? or should the create images that are then stored in<br>
a volume? What's the difference?<br>
<br>
Technically, the answer is probably none, but from a deployment and<br>
usability perspective, there's a huge difference that needs to be<br>
considered.<br>
<br>
I'm not saying it's a bad idea, I'm just saying we need to get this<br>
story straight and probably just pick one (? /me *shrugs*)<br>
<span class=""><br>
>> While I still don't fully understand the need of this driver, I think<br>
>> there's a bigger problem we need to solve now. We have a partially<br>
>> implemented driver that is almost useless and it's creating lots of<br>
>> confusion in users that are willing to use it but keep hitting 500<br>
>> errors because there's nothing they can do with it except for creating<br>
>> an image that points to an existing volume.<br>
>><br>
>> I'd like us to discuss what the exact plan for this driver moving<br>
>> forward is, what is missing and whether it'll actually be completed<br>
>> during Kilo.<br>
><br>
> I'd like to enhance cinder driver of course, but currently it blocked<br>
> on one thing it needs a correct people believed way [0] to access<br>
> volume from Glance (for both data and control plane, e.g. creating<br>
> image and upload bits). During H cycle I was told cinder will release<br>
> a separated lib soon, called Brick[0], which could be used from other<br>
> project to allow them access volume directly from cinder, but seems it<br>
> didn't ready to use still until now. But anyway, we can talk this with<br>
> cinder team to get Brick moving forward.<br>
><br>
> [0] <a href="https://review.openstack.org/#/c/20593/" target="_blank">https://review.openstack.org/#/c/20593/</a><br>
> [1] <a href="https://wiki.openstack.org/wiki/CinderBrick" target="_blank">https://wiki.openstack.org/wiki/CinderBrick</a><br>
><br>
> I really appreciated if somebody could show me a clear plan/status on<br>
> CinderBrick, I still think it's a good way to go for glance cinder<br>
> driver.<br>
<br>
</span>+1 Mike? John ? Any extra info here?<br>
<br>
If the brick's lib is not going to be released before k-2, I think we<br>
should just remove this driver until we can actually complete the work.<br>
<br>
As it is right now, it doesn't add any benefit and there's nothing this<br>
driver adds that cannot be done already (creating volumes from images,<br>
that is).<br>
<span class=""><br>
>> If there's a slight chance it won't be completed in Kilo, I'd like to<br>
>> propose getting rid of it - with a deprecation period, I guess - and<br>
>> giving it another chance in the future when it can be fully implemented.<br>
>><br>
>> [0] <a href="https://blueprints.launchpad.net/glance/+spec/glance-cinder-driver" target="_blank">https://blueprints.launchpad.net/glance/+spec/glance-cinder-driver</a><br>
>> [1] <a href="https://review.openstack.org/#/c/32864/" target="_blank">https://review.openstack.org/#/c/32864/</a><br>
<br>
</span>Fla<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
--<br>
@flaper87<br>
Flavio Percoco<br>
<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>
</div></div></blockquote></div><br></div><div class="gmail_extra">"Sorry State" is probably fair, the issue here is as you pointed out it's something that's partially done.  To be clear about the intended use-case here; my intent was mostly to utilize Cinder Block Devices similar to the model Ceph has in place.  We can make instance creation and migration quite a bit more efficient IMO and also there are some of the points you made around cloning and creating new volumes.  </div><div class="gmail_extra"><br></div><div class="gmail_extra">Ideas started spreading from there to "Using a Read Only Cinder Volume per image", to "A Glance owned Cinder Volume" that would behave pretty much the current local disk/file-system model (Create a Cinder Volume for Glance, attach it to the Glance Server, partition, format and mount... use as image store).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Anyway, I'd like to propose that we either move forward or remove the code that's there now.  My opinion is that we resync on specs and bp's by K-1 and have an agreed upon plan and way forward.  Otherwise remove it, you're absolutely right that it's causing a good deal of confusion.  I've received a fair number of inquiries from people trying to use it and I have to say "ummmm..... yeah, about that" which is not fun.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,</div><div class="gmail_extra">John</div></div>