[openstack-dev] [Glance][Cinder] The sorry state of cinder's driver in Glance

Flavio Percoco flavio at redhat.com
Thu Oct 23 07:11:32 UTC 2014


On 10/22/2014 04:46 PM, Zhi Yan Liu wrote:
> Replied in inline.
> 
> On Wed, Oct 22, 2014 at 9:33 PM, Flavio Percoco <flavio at redhat.com> wrote:
>> On 10/22/2014 02:30 PM, Zhi Yan Liu wrote:
>>> Greetings,
>>>
>>> On Wed, Oct 22, 2014 at 4:56 PM, Flavio Percoco <flavio at redhat.com> wrote:
>>>> Greetings,
>>>>
>>>> Back in Havana a, partially-implemented[0][1], Cinder driver was merged
>>>> in Glance to provide an easier and hopefully more consistent interaction
>>>> between glance, cinder and nova when it comes to manage volume images
>>>> and booting from volumes.
>>>
>>> With my idea, it not only for VM provisioning and consuming feature
>>> but also for implementing a consistent and unified block storage
>>> backend for image store.  For historical reasons, we have implemented
>>> a lot of duplicated block storage drivers between glance and cinder,
>>> IMO, cinder could regard as a full-functional block storage backend
>>> from OpenStack's perspective (I mean it contains both data and control
>>> plane), glance could just leverage cinder as a unified block storage
>>> backend. Essentially, Glance has two kind of drivers, block storage
>>> driver and object storage driver (e.g. swift and s3 driver),  from
>>> above opinion, I consider to give glance a cinder driver is very
>>> sensible, it could provide a unified and consistent way to access
>>> different kind of block backend instead of implement duplicated
>>> drivers in both projects.
>>
>> Let me see if I got this right. You're suggesting to have a cinder
>> driver in Glance so we can basically remove the
>> 'create-volume-from-image' functionality from Cinder. is this right?
>>
> 
> I don't think we need to remove any feature as an existing/reasonable
> use case from end user's perspective, 'create-volume-from-image' is a
> useful function and need to keep as-is to me, but I consider we can do
> some changes for internal implementation if we have cinder driver for
> glance, e.g. for this use case, if glance store image as a volume
> already then cinder can create volume effectively - to leverage such
> capability from backend storage, I think this case just like ceph
> current way on this situation (so a duplication example again).
> 
>>> I see some people like to see implementing similar drivers in
>>> different projects again and again, but at least I think this is a
>>> hurtless and beneficial feature/driver.
>>
>> It's not as harmless as it seems. There are many users confused as to
>> what the use case of this driver is. For example, should users create
>> volumes from images? or should the create images that are then stored in
>> a volume? What's the difference?
> 
> I'm not sure I understood all concerns from those folks, but for your
> examples, one key reason I think is that they still think it in
> technical way to much. I mean create-image-from-volume and
> create-volume-from-image are useful and reasonable _use case_ from end
> user's perspective because volume and image are totally different
> concept for end user in cloud context (at least, in OpenStack
> context), the benefits/purpose of leverage cinder store/driver in
> glance is not to change those concepts and existing use case for end
> user/operator but to try to help us implement those feature
> efficiently in glance and cinder inside, IMO, including low the
> duplication as much as possible which as I mentioned before. So, in
> short, I see the impact of this idea is on _implementation_ level,
> instead on the exposed _use case_ level.

While I agree it has a major impact in the implementation of things, I
still think it has an impact from an use-case perspective, even an
operations perspective.

For example, If I were to deploy Glance on top of Cinder, I need to
first make Cinder accessible from Glance, which it might not be. This is
probably not a big deal. However, I also need to figure out things like:
How should I expose this to my users? Do they need it? or should I keep
it internal?

Furthermore, I'd need to answer questions like: Now that images can be
created in volumes, I need to take that into account when doing my size
planning.

Not saying these are blockers for this feature but I just want to make
clear that from a users perspective, it's not as simple as enabling a
new driver in Glance.


>> Technically, the answer is probably none, but from a deployment and
>> usability perspective, there's a huge difference that needs to be
>> considered.
> 
> According to my above explanations, IMO, this driver/idea couldn't
> (and shouldn't) break existing concept and use case for end
> user/operator, but if I still miss something pls let me know.

According to the use-cases explained in this thread (also in the emails
from John and Mathieu) this is something that'd be good having. I'm
looking forward to seeing the driver completed.

As John mentioned in his email, we should probably sync again in K-1 to
see if there's been some progress on the bricks side and the other
things this driver depends on. If there hasn't, we should probably get
rid of it and add it back once it can actually be full-featured.

Cheers,
Flavio


-- 
@flaper87
Flavio Percoco



More information about the OpenStack-dev mailing list