On Thu, Mar 20, 2014 at 3:43 PM, Josh Durgin <josh.durgin@xxxxxxxxxxx> wrote: > On 03/20/2014 02:07 PM, Dmitry Borodaenko wrote: >> The patch series that implemented clone operation for RBD backed >> ephemeral volumes in Nova did not make it into Icehouse. We have tried >> our best to help it land, but it was ultimately rejected. Furthermore, >> an additional requirement was imposed to make this patch series >> dependent on full support of Glance API v2 across Nova (due to its >> dependency on direct_url that was introduced in v2). >> >> You can find the most recent discussion of this patch series in the >> FFE (feature freeze exception) thread on openstack-dev ML: >> http://lists.openstack.org/pipermail/openstack-dev/2014-March/029127.html >> >> As I explained in that thread, I believe this feature is essential for >> using Ceph as a storage backend for Nova, so I'm going to try and keep >> it alive outside of OpenStack mainline until it is allowed to land. >> >> I have created rbd-ephemeral-clone branch in my nova repo fork on GitHub: >> https://github.com/angdraug/nova/tree/rbd-ephemeral-clone >> >> I will keep it rebased over nova master, and will create an >> rbd-ephemeral-clone-stable-icehouse to track the same patch series >> over nova stable/icehouse once it's branched. I also plan to make sure >> that this patch series is included in Mirantis OpenStack 5.0 which >> will be based on Icehouse. >> >> If you're interested in this feature, please review and test. Bug >> reports and patches are welcome, as long as their scope is limited to >> this patch series and is not applicable for mainline OpenStack. > > Thanks for taking this on Dmitry! Having rebased those patches many > times during icehouse, I can tell you it's often not trivial. Indeed, I get conflicts every day lately, even in the current bugfixing stage of the OpenStack release cycle. I have a feeling it will not get easier when Icehouse is out and Juno is in full swing. > Do you think the imagehandler-based approach is best for Juno? I'm > leaning towards the older way [1] for simplicity of review, and to > avoid using glance's v2 api by default. > [1] https://review.openstack.org/#/c/46879/ Excellent question, I have thought long and hard about this. In retrospect, requiring this change to depend on the imagehandler patch back in December 2013 proven to have been a poor decision. Unfortunately, now that it's done, porting your original patch from Havana to Icehouse is more work than keeping the new patch series up to date with Icehouse, at least short term. Especially if we decide to keep the rbd_utils refactoring, which I've grown to like. As far as I understand, your original code made use of the same v2 api call even before it was rebased over imagehandler patch: https://github.com/jdurgin/nova/blob/8e4594123b65ddf47e682876373bca6171f4a6f5/nova/image/glance.py#L304 If I read this right, imagehandler doesn't create the dependency on v2 api, the only reason it caused a problem was because it exposed the output of the same Glance API call to a code path that assumed a v1 data structure. If so, decoupling rbd clone patch from imagehandler will not help lift the full Glance API v2 support requirement, that v2 api call will still be there. Also, there's always a chance that imagehandler lands in Juno. If it does, we'd be forced to dust off the imagehandler based patch series again, and the effort spent on maintaining the old patch would be wasted. Given all that, and without making any assumptions about stability of the imagehandler patch in its current state, I'm leaning towards keeping it. If you think it's likely that it will cause us more problems than the Glance API v2 issue, or if you disagree with my analysis of that issue, please tell. > I doubt that full support for > v2 will land very fast in nova, although I'd be happy to be proven wrong. I'm sceptical about this, too. That's why right now my first priority is making sure this patch is usable and stable with Icehouse. Post-Icehouse, we'll have to see where glance v2 support in nova goes, if anywhere at all. Not much point making plans when we can't even tell if we'll have to rewrite this patch yet again for Juno. -- Dmitry Borodaenko _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |