Hopefully this flow means we can do rebuild root filesystem from snapshot/backup too? It seems rather artificially limiting to only do restore-from-image. I'd expect restore-from-snap to be a more common use case, personally.
On 9 April 2018 at 09:51, Gorka Eguileor <gegui...@redhat.com> wrote: > On 06/04, Matt Riedemann wrote: >> On 4/6/2018 5:09 AM, Matthew Booth wrote: >> > I think you're talking at cross purposes here: this won't require a >> > swap volume. Apart from anything else, swap volume only works on an >> > attached volume, and as previously discussed Nova will detach and >> > re-attach. >> > >> > Gorka, the Nova api Matt is referring to is called volume update >> > externally. It's the operation required for live migrating an attached >> > volume between backends. It's called swap volume internally in Nova. >> >> Yeah I was hoping we were just having a misunderstanding of what 'swap >> volume' in nova is, which is the blockRebase for an already attached volume >> to the guest, called from cinder during a volume retype or migration. >> >> As for the re-image thing, nova would be detaching the volume from the guest >> prior to calling the new cinder re-image API, and then re-attach to the >> guest afterward - similar to how shelve and unshelve work, and for that >> matter how rebuild works today with non-root volumes. >> >> -- >> >> Thanks, >> >> Matt >> >> __________________________________________________________________________ >> 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 > > Hi, > > Thanks for the clarification. When I was talking about "swapping" I was > referring to the fact that Nova will have to not only detach the volume > locally using OS-Brick, but it will also need to use new connection > information to do the attach after the volume has been re-imaged. > > As I see it, the process would look something like this: > > - Nova detaches volume using OS-Brick > - Nova calls Cinder re-image passing the node's info (like we do when > attaching a new volume) > - Cinder would: > - Ensure only that node is connected to the volume > - Terminate connection to the original volume > - If we can do optimized volume creation: > - If encrypted volume we create a copy of the encryption key on > Barbican or copy the ID field from the DB and ensure we don't > delete the Barbican key on the delete. > - Create new volume from image > - Swap DB fields to preserve the UUID > - Delete original volume > - If it cannot do optimized volume creation: > - Initialize+Attach volume to Cinder node > - DD the new image into the volume > - Detach+Terminate volume > - Initialize connection for the new volume to the Nova node > - Return connection information to the volume > - Nova attaches volume with OS-Brick using returned connection > information. > > So I agree, it's not a blockRebase operation, just a change in the > volume that is used. > > Regards, > 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 -- Duncan Thomas __________________________________________________________________________ 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
