Re: [openstack-dev] [Cinder] Cloning vs copying images
All, I'd like to ask the core reviewers to review both patch sets again since they are now basically the same. I'd like to see either merged so the bug cane closed and improve cinder (and ceph). We can simply determine preference by votes. Thanks Andrew Woodward Mirantis On Fri, Dec 6, 2013 at 10:11 AM, Dmitry Borodaenko wrote: > Dear All, > > The consensus in comments to both patches seems to be that the > decision to clone an image based on disk format should be made in each > driver, instead of being imposed on all drivers by the flow. Edward > has updated his patch to follow the same logic as my patch, and I have > updated my patch to include additional unit test improvements and > better log messages lifted from Edward's version. The only difference > between the patches now is that my patch passes the whole image_meta > dictionary into clone_image while Edward's patch only passes the > image_format string. > > Please review the patches once again and provide feedback on which > should be merged. I naturally favor my version, which came up first, > is consistent with other driver methods which also pass image_meta > dictionary around, and prevents further refactoring down the road if > any driver comes up with a reason to consider other fields of > image_meta (e.g. size) when deciding whether an image can be cloned. > > Thanks, > Dmitry Borodaenko > > On Mon, Dec 2, 2013 at 11:29 AM, Dmitry Borodaenko > wrote: > > Hi OpenStack, particularly Cinder backend developers, > > > > Please consider the following two competing fixes for the same problem: > > > > https://review.openstack.org/#/c/58870/ > > https://review.openstack.org/#/c/58893/ > > > > The problem being fixed is that some backends, specifically Ceph RBD, > > can only boot from volumes created from images in a certain format, in > > RBD's case, RAW. When an image in a different format gets cloned into > > a volume, it cannot be booted from. Obvious solution is to refuse > > clone operation and copy/convert the image instead. > > > > And now the principal question: is it safe to assume that this > > restriction applies to all backends? Should the fix enforce copy of > > non-RAW images for all backends? Or should the decision whether to > > clone or copy the image be made in each backend? > > > > The first fix puts this logic into the RBD backend, and makes changes > > necessary for all other backends to have enough information to make a > > similar decision if necessary. The problem with this approach is that > > it's relatively intrusive, because driver clone_image() method > > signature has to be changed. > > > > The second fix has significantly less code changes, but it does > > prevent cloning non-RAW images for all backends. I am not sure if this > > is a real problem or not. > > > > Can anyone point at a backend that can boot from a volume cloned from > > a non-RAW image? I can think of one candidate: GPFS is a file-based > > backend, while GPFS has a file clone operation. Is GPFS backend able > > to boot from, say, a QCOW2 volume? > > > > Thanks, > > > > -- > > Dmitry Borodaenko > > > > -- > Dmitry Borodaenko > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- If google has done it, Google did it right! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Cloning vs copying images
Dear All, The consensus in comments to both patches seems to be that the decision to clone an image based on disk format should be made in each driver, instead of being imposed on all drivers by the flow. Edward has updated his patch to follow the same logic as my patch, and I have updated my patch to include additional unit test improvements and better log messages lifted from Edward's version. The only difference between the patches now is that my patch passes the whole image_meta dictionary into clone_image while Edward's patch only passes the image_format string. Please review the patches once again and provide feedback on which should be merged. I naturally favor my version, which came up first, is consistent with other driver methods which also pass image_meta dictionary around, and prevents further refactoring down the road if any driver comes up with a reason to consider other fields of image_meta (e.g. size) when deciding whether an image can be cloned. Thanks, Dmitry Borodaenko On Mon, Dec 2, 2013 at 11:29 AM, Dmitry Borodaenko wrote: > Hi OpenStack, particularly Cinder backend developers, > > Please consider the following two competing fixes for the same problem: > > https://review.openstack.org/#/c/58870/ > https://review.openstack.org/#/c/58893/ > > The problem being fixed is that some backends, specifically Ceph RBD, > can only boot from volumes created from images in a certain format, in > RBD's case, RAW. When an image in a different format gets cloned into > a volume, it cannot be booted from. Obvious solution is to refuse > clone operation and copy/convert the image instead. > > And now the principal question: is it safe to assume that this > restriction applies to all backends? Should the fix enforce copy of > non-RAW images for all backends? Or should the decision whether to > clone or copy the image be made in each backend? > > The first fix puts this logic into the RBD backend, and makes changes > necessary for all other backends to have enough information to make a > similar decision if necessary. The problem with this approach is that > it's relatively intrusive, because driver clone_image() method > signature has to be changed. > > The second fix has significantly less code changes, but it does > prevent cloning non-RAW images for all backends. I am not sure if this > is a real problem or not. > > Can anyone point at a backend that can boot from a volume cloned from > a non-RAW image? I can think of one candidate: GPFS is a file-based > backend, while GPFS has a file clone operation. Is GPFS backend able > to boot from, say, a QCOW2 volume? > > Thanks, > > -- > Dmitry Borodaenko -- Dmitry Borodaenko ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Cloning vs copying images
Hi Dmitry, Currently, the GPFS Cinder driver can use GPFS's file cloning mechanism when creating a bootable volume from Glance if the source image is RAW. If the source image is not raw, the driver creates the boot volume by converting the source image to RAW. Regards, Bill Owen billo...@us.ibm.com GPFS and OpenStack 520-799-4829 From: Dmitry Borodaenko To: openstack-dev@lists.openstack.org, Date: 02/12/2013 09:32 PM Subject:[openstack-dev] [Cinder] Cloning vs copying images Hi OpenStack, particularly Cinder backend developers, Please consider the following two competing fixes for the same problem: https://review.openstack.org/#/c/58870/ https://review.openstack.org/#/c/58893/ The problem being fixed is that some backends, specifically Ceph RBD, can only boot from volumes created from images in a certain format, in RBD's case, RAW. When an image in a different format gets cloned into a volume, it cannot be booted from. Obvious solution is to refuse clone operation and copy/convert the image instead. And now the principal question: is it safe to assume that this restriction applies to all backends? Should the fix enforce copy of non-RAW images for all backends? Or should the decision whether to clone or copy the image be made in each backend? The first fix puts this logic into the RBD backend, and makes changes necessary for all other backends to have enough information to make a similar decision if necessary. The problem with this approach is that it's relatively intrusive, because driver clone_image() method signature has to be changed. The second fix has significantly less code changes, but it does prevent cloning non-RAW images for all backends. I am not sure if this is a real problem or not. Can anyone point at a backend that can boot from a volume cloned from a non-RAW image? I can think of one candidate: GPFS is a file-based backend, while GPFS has a file clone operation. Is GPFS backend able to boot from, say, a QCOW2 volume? Thanks, -- Dmitry Borodaenko ___ 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] [Cinder] Cloning vs copying images
Dmitry, You are correct. I made the same comment on the review before seeing this thread. Let's see how both patches turn out and we'll choose one. :) Thanks, Avishay From: Dmitry Borodaenko To: openstack-dev@lists.openstack.org, Date: 12/02/2013 09:32 PM Subject:[openstack-dev] [Cinder] Cloning vs copying images Hi OpenStack, particularly Cinder backend developers, Please consider the following two competing fixes for the same problem: https://review.openstack.org/#/c/58870/ https://review.openstack.org/#/c/58893/ The problem being fixed is that some backends, specifically Ceph RBD, can only boot from volumes created from images in a certain format, in RBD's case, RAW. When an image in a different format gets cloned into a volume, it cannot be booted from. Obvious solution is to refuse clone operation and copy/convert the image instead. And now the principal question: is it safe to assume that this restriction applies to all backends? Should the fix enforce copy of non-RAW images for all backends? Or should the decision whether to clone or copy the image be made in each backend? The first fix puts this logic into the RBD backend, and makes changes necessary for all other backends to have enough information to make a similar decision if necessary. The problem with this approach is that it's relatively intrusive, because driver clone_image() method signature has to be changed. The second fix has significantly less code changes, but it does prevent cloning non-RAW images for all backends. I am not sure if this is a real problem or not. Can anyone point at a backend that can boot from a volume cloned from a non-RAW image? I can think of one candidate: GPFS is a file-based backend, while GPFS has a file clone operation. Is GPFS backend able to boot from, say, a QCOW2 volume? Thanks, -- Dmitry Borodaenko ___ 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
