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

2014-10-24 Thread Mike Perez
On 09:11 Thu 23 Oct , Flavio Percoco wrote:
 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.

I'm unsure if Brick [1] will be completed in time. With that in mind, even if
we were to deprecate the glance driver for Kilo, Brick will likely be done by
then and we would just be removing the deprecation in L, assuming the driver is
completed in L. I think that would be confusing to users. It's unfortunate this
was merged in the current state, but I would just say leave things as is with
intentions at the latest to have the driver completed in L. If we're afraid no
one is going to complete the driver, deprecate it now.

[1] - https://github.com/hemna/cinder-brick

-- 
Mike Perez

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


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

2014-10-24 Thread Flavio Percoco
On 10/24/2014 03:29 PM, Mike Perez wrote:
 On 09:11 Thu 23 Oct , Flavio Percoco wrote:
 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.
 
 I'm unsure if Brick [1] will be completed in time. With that in mind, even if
 we were to deprecate the glance driver for Kilo, Brick will likely be done by
 then and we would just be removing the deprecation in L, assuming the driver 
 is
 completed in L. I think that would be confusing to users. It's unfortunate 
 this
 was merged in the current state, but I would just say leave things as is with
 intentions at the latest to have the driver completed in L. If we're afraid no
 one is going to complete the driver, deprecate it now.
 
 [1] - https://github.com/hemna/cinder-brick

Thanks, Mike. This is great feedback.

I wonder how strong is the dependency between the cinder driver and
bricks. I mean, it'd be cool if we could complete the implementation in
a perhaps not so optimized way - on top of cinder's API? - and then use
the bricks library when it's done.

Thoughts on the above? It sounds hacky, I know. :)

Cheers,
Flavio

-- 
@flaper87
Flavio Percoco

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


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

2014-10-24 Thread John Griffith


On Fri, Oct 24, 2014, at 07:59 AM, Flavio Percoco wrote:
 On 10/24/2014 03:29 PM, Mike Perez wrote:
  On 09:11 Thu 23 Oct , Flavio Percoco wrote:
  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.
  
  I'm unsure if Brick [1] will be completed in time. With that in mind, even 
  if
  we were to deprecate the glance driver for Kilo, Brick will likely be done 
  by
  then and we would just be removing the deprecation in L, assuming the 
  driver is
  completed in L. I think that would be confusing to users. It's unfortunate 
  this
  was merged in the current state, but I would just say leave things as is 
  with
  intentions at the latest to have the driver completed in L. If we're afraid 
  no
  one is going to complete the driver, deprecate it now.
  
  [1] - https://github.com/hemna/cinder-brick
 
 Thanks, Mike. This is great feedback.
 
 I wonder how strong is the dependency between the cinder driver and
 bricks. I mean, it'd be cool if we could complete the implementation in
 a perhaps not so optimized way - on top of cinder's API? - and then use
 the bricks library when it's done.

I fear my mention of Brick may have thrown things out of whack here. 
Frankly for now I think that whole thing should be ignored as it
pertains to this topic.  We've made the mistake of deferring things
based on that whole idea in the past and it hasn't gone well. 

Glance shouldn't need most of the stuff that's going on in there anyway
I don't think.  I think Flavio keyed in on the main point IMO how
strong of a dependency, ideally I hope the answer is not very.  The
other thing about this is my conversations with folks in the past were
that Glance should be kept pretty darn light in terms of any data path
type stuff.  We really should intend for it to be not much more than a
registry and serve as a conduit.  If that's changed or I'm wrong on that
feel free to shout, but previous conversations with Mark suggested that
moving things like initiators and targets in to Glance was not ideal
(and I agree). 

 
 Thoughts on the above? It sounds hacky, I know. :)

Yes, please, let's move forward with it like we were saying earlier. 
There's still a number of gaps and some hand waving I think so really
it's something I think we just need to dive into.

 
 Cheers,
 Flavio
 
 -- 
 @flaper87
 Flavio Percoco
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


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

2014-10-23 Thread Flavio Percoco
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 fla...@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 fla...@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



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

2014-10-22 Thread Zhi Yan Liu
Greetings,

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

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.

[0] https://review.openstack.org/#/c/20593/
[1] https://wiki.openstack.org/wiki/CinderBrick

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
driver.


 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] https://blueprints.launchpad.net/glance/+spec/glance-cinder-driver
 [1] https://review.openstack.org/#/c/32864/


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

zhiyan

 Cheers,
 Flavio

 --
 @flaper87
 Flavio Percoco

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

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


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

2014-10-22 Thread Flavio Percoco
On 10/22/2014 02:30 PM, Zhi Yan Liu wrote:
 Greetings,
 
 On Wed, Oct 22, 2014 at 4:56 PM, Flavio Percoco fla...@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 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?

Technically, the answer is probably none, but from a deployment and
usability perspective, there's a huge difference that needs to be
considered.

I'm not saying it's a bad idea, I'm just saying we need to get this
story straight and probably just pick one (? /me *shrugs*)

 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.
 
 [0] https://review.openstack.org/#/c/20593/
 [1] https://wiki.openstack.org/wiki/CinderBrick
 
 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
 driver.

+1 Mike? John ? Any extra info here?

If the brick's lib is not going to be released before k-2, I think we
should just remove this driver until we can actually complete the work.

As it is right now, it doesn't add any benefit and there's nothing this
driver adds that cannot be done already (creating volumes from images,
that is).

 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] https://blueprints.launchpad.net/glance/+spec/glance-cinder-driver
 [1] https://review.openstack.org/#/c/32864/

Fla


-- 
@flaper87
Flavio Percoco

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


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

2014-10-22 Thread John Griffith
On Wed, Oct 22, 2014 at 7:33 AM, Flavio Percoco fla...@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 fla...@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 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?

 Technically, the answer is probably none, but from a deployment and
 usability perspective, there's a huge difference that needs to be
 considered.

 I'm not saying it's a bad idea, I'm just saying we need to get this
 story straight and probably just pick one (? /me *shrugs*)

  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.
 
  [0] https://review.openstack.org/#/c/20593/
  [1] https://wiki.openstack.org/wiki/CinderBrick
 
  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
  driver.

 +1 Mike? John ? Any extra info here?

 If the brick's lib is not going to be released before k-2, I think we
 should just remove this driver until we can actually complete the work.

 As it is right now, it doesn't add any benefit and there's nothing this
 driver adds that cannot be done already (creating volumes from images,
 that is).

  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] https://blueprints.launchpad.net/glance/+spec/glance-cinder-driver
  [1] https://review.openstack.org/#/c/32864/

 Fla


 --
 @flaper87
 Flavio Percoco

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


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.

Ideas started spreading from there to Using a Read Only Cinder Volume per
image, to A Glance owned 

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

2014-10-22 Thread Zhi Yan Liu
Replied in inline.

On Wed, Oct 22, 2014 at 9:33 PM, Flavio Percoco fla...@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 fla...@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.


 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.

zhiyan


 I'm not saying it's a bad idea, I'm just saying we need to get this
 story straight and probably just pick one (? /me *shrugs*)

 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.

 [0] https://review.openstack.org/#/c/20593/
 [1] https://wiki.openstack.org/wiki/CinderBrick

 I really appreciated 

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

2014-10-22 Thread Mathieu Gagné

On 2014-10-22 10:05 AM, John Griffith wrote:


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).



To add to John Griffith's explanation:

This is a feature we have wanted for *several* months and finally 
implemented in-house in a different way directly in Cinder.


Creating a volume from an image can takes *several* minutes depending on 
the Cinder backend used. For someone using BFV as its main way to boot 
instances, it is a *HUGE* issue.


This causes several problems:

- When BFV, Nova thinks the volume creation failed because it took more 
than 2 minutes to create the volume from the image. Nova will then 
retry the volume creation, still without success, and instance will go 
in ERROR state.


You now have 2 orphan volumes in Cinder. This is because Nova cannot 
cleanup after itself properly due to volumes still being in creating 
state when deletion is attempted by Nova.


- So you try to create the volume yourself first and ask Nova to boot on 
it. When creating a volume from an image in Cinder (not through Nova), 
from a UX perspective, this time is too long.


Time required adds up when using a SolidFire backend with QoS. You have 
the time to get several coffees and a whole breakfast with your friends 
to talk about how creation a volume from an image is too damn slow.


What we did to fix the issue:

- We created a special tenant with golden volumes which are in fact 
volumes created from images. Those golden volumes are used to optimize 
the volume creation.


The SolidFire driver has been modified so that when you create a volume 
from an image, it first tries to see if there is a corresponding golden 
volume in that special tenant. If one is found, volume is cloned into 
the appropriate tenant in a matter of seconds. If none is found, normal 
creation process is used.



AFAIK, some storage backends (like Ceph) addressed the issue by 
implementing themselves in all the OpenStack services: Nova, Glance 
and Cinder. They now have the ability to optimize each steps of the 
lifecycle of an instance/volume by simply cloning volumes instead of 
re-downloading a whole image to finally end up in the same backend the 
original image was stored in.


While this is cool for Ceph, other backends don't have this luxury and 
we are stucked in this sorry state.


--
Mathieu

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