[openstack-dev] [Cinder] Cloning vs copying images

Andrew Woodward xarses at gmail.com
Fri Dec 13 01:48:33 UTC 2013


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 <dborodaenko at mirantis.com
> 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
> <dborodaenko at 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
If google has done it, Google did it right!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131212/f04b7cd0/attachment.html>


More information about the OpenStack-dev mailing list