On 29/03, Sean McGinnis wrote: > > This is the spec [0] about rebuild the volumed backed server. > > The question raised in the spec is about how to bandle the root volume. > > Finally,in Nova team,we think that the cleanest / best solution to this is > > to > > add a volume action API to cinder for re-imaging the volume.Once that is > > available in a new cinder v3 microversion, nova can use it. The reason I > > ... > > So Nova team want Cinder to achieve the re-image api.But, I see a spec > > about volume revert by snapshot[1].It is so good for rebuild operation.In > > short,I have two ideas,one is change the volume revert by snapshot spec to > > re-image spec,not only it can let the volume revert by snapshot,but also can > > re-image the volume which the image's size is greater than 0;another idea is > > add a only re-image spec,it only can re-image the volume which the image's > > size is greater than 0. > > > > I do not think changing the revert to snapshot implementation is appropriate > here. There may be some cases where this can get the desired result, but there > is no guarantee that there is a snapshot on the volume's base image state to > revert to. It also would not make sense to overload this functionality to > "revert to snapshot if you can, otherwise do all this other stuff instead." > > This would need to be a new API (microversioned) to add a reimage call. I > wouldn't expect implementation to be too difficult as we already have that > functionality for new volumes. We would just need to figure out the most > appropriate way to take an already in-use volume, detach it, rewrite the > image, > then reattach it. >
Hi, The implementation may be more complex that we think, as we have 4 create volume from image mechanisms we have to consider: - When Glance is using Cinder as backend - When using Glance image location to do cloning - When using Cinder cache and we do cloning - Basic case where we download the image, attach the volume, and copy the data. The only simple, yet efficient, solution I can see is calling the driver's delete volume method (without soft-deleting it from the DB), clear the volume DB information of the image metadata, and then run the create volume from image flow with the same volume information but the new image metadata. I can only see one benefit from implementing this feature in Cinder versus doing it in Nova, and that is that we can preserve the volume's UUID, but I don't think this is even relevant for this use case, so why is it better to implement this in Cinder than in Nova? Cheers, Gorka. > Ideally, from my perspective, Nova would take care of the detach/attach > portion > and Cinder would only need to take care of imaging the volume. > > Sean > > __________________________________________________________________________ > 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 __________________________________________________________________________ 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
