On Wed, Oct 22, 2014 at 4:56 PM, Flavio Percoco <> 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.

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.

> While I still don't fully understand the need of this driver, I think
> there's a bigger problem we need to solve now. We have a partially
> implemented driver that is almost useless and it's creating lots of
> confusion in users that are willing to use it but keep hitting 500
> errors because there's nothing they can do with it except for creating
> an image that points to an existing volume.
> I'd like us to discuss what the exact plan for this driver moving
> forward is, what is missing and whether it'll actually be completed
> during Kilo.

I'd like to enhance cinder driver of course, but currently it blocked
on one thing it needs a correct people believed way [0] to access
volume from Glance (for both data and control plane, e.g. creating
image and upload bits). During H cycle I was told cinder will release
a separated lib soon, called Brick[0], which could be used from other
project to allow them access volume directly from cinder, but seems it
didn't ready to use still until now. But anyway, we can talk this with
cinder team to get Brick moving forward.


I really appreciated if somebody could show me a clear plan/status on
CinderBrick, I still think it's a good way to go for glance cinder

> If there's a slight chance it won't be completed in Kilo, I'd like to
> propose getting rid of it - with a deprecation period, I guess - and
> giving it another chance in the future when it can be fully implemented.
> [0]
> [1]

It obviously depends, according to my above information, but I'd like to try.


> Cheers,
> Flavio
> --
> @flaper87
> Flavio Percoco
> _______________________________________________
> OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to