On 05/04, Matt Riedemann wrote: > On 4/5/2018 3:15 AM, Gorka Eguileor wrote: > > But just to be clear, Nova will have to initialize the connection with > > the re-imagined volume and attach it again to the node, as in all cases > > (except when defaulting to downloading the image and dd-ing it to the > > volume) the result will be a new volume in the backend. > > Yeah I think I pointed this out earlier in this thread on what I thought the > steps would be on the nova side with respect to creating a new empty > attachment to keep the volume 'reserved' while we delete the old attachment, > re-image the volume, and then update the volume attachment for the new > connection. I think that would be similar to how shelve and unshelve works > in nova. > > Would this really require a swap volume call from Cinder? I'd hope not since > swap volume in itself is a pretty gross operation on the nova side. > > -- > > Thanks, > > Matt >
Hi Matt, Yes, it will require a volume swap, with the worst case scenario exception where we dd the image into the volume. In the same way that anyone would expect a re-imaging preserving the volume id, one would also expect it to behave like creating a new volume from the same image: be as fast and take up as much space on the backend. And to do so we have to use existing optimized mechanisms that will only work when creating a new volume. The alternative would be to have the worst case scenario as the default (attach and dd the image) and make *ALL* Cinder drivers implement the optimized mechanism where they can efficiently re-imagine a volume. I can't talk for the Cinder team, but I for one would oppose this alternative. Cheers, Gorka. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
