Comment 15 for bug 1464259

volume2 (created from the volume snapshot) is attached to server2 here:

http://logs.openstack.org/20/218120/3/check/gate-tempest-dsvm-full-ceph/2349f2d/logs/screen-n-cpu.txt.gz#_2015-12-07_05_51_12_600

2015-12-07 05:51:12.600 DEBUG keystoneclient.session [req-0467c440-1f5b-4a74-9ba8-d266d6b0b182 tempest-TestVolumeBootPatternV2-1635783358 tempest-TestVolumeBootPatternV2-232134174] REQ: curl -g -i -X POST http://127.0.0.1:8776/v2/37d3bb6fbd8b459ebd1459afe434900a/volumes/19efe5d8-fa71-4569-b806-dfe2e0080b7f/action -H "User-Agent: python-cinderclient" -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}3f5cbbbb6773d2637527121a8ae0faa71adbc434" -d '{"os-attach": {"instance_uuid": "91817c91-6305-4e44-9f53-0eca5a27aa8d", "mountpoint": "/dev/vda", "mode": "rw"}}' _http_log_request /usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:198

We set the volume_id on the bdm here:

https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L396

And that would be updated in the database once the attach method is done.

We start deleting the instance here (1 second later):

http://logs.openstack.org/20/218120/3/check/gate-tempest-dsvm-full-ceph/2349f2d/logs/screen-n-cpu.txt.gz#_2015-12-07_05_51_13_998

But I'm still not sure why the snapshot bdm isn't updated with the volume_id in the database after we created it. Maybe we should save that off immediately before trying to attach the volume in case we need to teardown.