Admin creates volume backed instance snapshot in image tenant

[Feodor Tersin]

For instance booted from volume with legacy bdm and image (this method is documented as workaround in http://docs.openstack.org/grizzly/openstack-ops/content/attach_block_storage.html) admin user creates instance snapshot in the image tenant rather than current tenant.
Created snapshot cannot be used.

Environment: DevStack

Steps to reproduce:
1 Create bootable volume from public image from not current tenant.
For example, use demo tenant in DevStack.
$ cinder create --image-id xxx 1
Note: I used cirros-0.3.2-x86_64-uec ami image.

2 Boot an instance from the volume passing the original image.
$ nova boot --flavor m1.nano --image xxx --block-device-mapping /dev/vda=yyy inst

3 Create instance snapshot under admin user
$ nova image-create inst snap

4 List images and make sure there is no the created snapshot.
$ glance image-list

5 List images from the original image tenant and found the snapshot.
$ glance --os-tenant-name nnn image-list

snapshot_volume_backed in nova/compute/api.py receives image in image_meta parameter, cleans some attributes, but forgets to deal something with owner attribute.

[Feodor Tersin (ftersin)]

https://review.openstack.org/#/c/94917/

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/95522

[Jay Pipes (jaypipes)]

Why are you passing --image XXX to the nova boot command as opposed to just booting from the volume?

[Feodor Tersin (ftersin)]

There is the set of bugs produced by other ways of launch an instance:
https://bugs.launchpad.net/nova/+bug/1322180
https://bugs.launchpad.net/nova/+bug/1324400

Also at the moment of the bug registration https://bugs.launchpad.net/nova/+bug/1322157 was actual.

Thus at that time usage --image XXX was the way to launch a volume backed image with the fewest problems.

So in the bug description i used this way to demonstrate that the problem is actual even for the most operable way of launch instance.

But this problem is not dependent of method of launching.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Feodor Tersin (<email address hidden>) on branch: master
Review: https://review.openstack.org/95522
Reason: Bug #1322157 is resolved by already committed https://review.openstack.org/#/c/93649/.

There is no reason for me to refactor nova when no one looked this changes within two weeks.

[Tracy Jones (tjones-i)]

this has not been touched in a long time and the patches are abandoned. Please set back to in progress if you start to work on it

[Feodor Tersin (ftersin)]

the actual review is https://review.openstack.org/#/c/94917/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/94917
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=a55f41492e5ce9bbc2f2ef3435a7e7e65bf6cb3e
Submitter: Jenkins
Branch: master

commit a55f41492e5ce9bbc2f2ef3435a7e7e65bf6cb3e
Author: ftersin <email address hidden>
Date: Thu May 22 20:01:45 2014 +0400

    Store volume backed snapshot in current tenant.

    Fix owner of a creating volume backed snapshot.

    Snapshot of an instance booted on a volume based on another tenant's
    public image is created in the wrong tenant when invoked by admin.

    Snapshot metadata (including owner) is based on image metadata. But
    when the snapshot is being created by admin, Glance doesn't change
    it's owner if it's set. So we forcibly remove owner (tenant)
    attribute from image metadata.

    Change-Id: I662dfa4f81e24cb2553ffa2578f4c8530eee9fd3
    Closes-Bug: #1322195