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 <dborodae...@mirantis.com> 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 OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev