Create Volume from a 0-byte reference (block_device_mapping) Glance image fails

Bug #1733450 reported by Dmitry Sutyagin
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mirantis OpenStack
Invalid
Undecided
Unassigned
9.x
Confirmed
Low
MOS Maintenance

Bug Description

Issue present in MOS 9.x
Issue is not present in MOS 7.x
Steps to reproduce via Horizon:
1. spawn an instance with "Create a new Volume" enabled
2. click "Instance Snapshot"
3. click "Create Volume" for the created 0-byte image

Originally reported in https://bugs.launchpad.net/mos/+bug/1666450.
Although it was decided that the 0-byte image is a "won't fix", this particular issue with "create volume" should be a bug, because it is possible to spawn a new VM from the 0-byte image, if "Create a new Volume" is used for the new VM. This means that functionality to create a volume from such image works; however it does not work from Images tab.

I will try to troubleshoot the issue and find the root cause. So far it looks like we hit the code here:
https://github.com/openstack/cinder/blob/master/cinder/volume/flows/manager/create_volume.py#L854
when using Images tab; however we do not hit it when we create a VM with "Create a new Volume", meaning one of self.driver.clone_image or self._clone_image_volume return cloned = True. This needs more debugging.

Revision history for this message
Dmitry Sutyagin (dsutyagin) wrote :

test showed that with subsequent VM boot with "Create a new Volume", this function (_create_from_image) is not used at all. Need to find what function is used, and somehow refer to the same code when "Create Volume" is used.

Revision history for this message
Dmitry Sutyagin (dsutyagin) wrote :

Looks like it's indeed an issue in Horizon (or Glance?).
Here is how requests to Cinder API look like:
 - VM is spawn from image with Create a new Volume: http://paste.openstack.org/show/626882/
 - Create Volume is used on Images tab: - http://paste.openstack.org/show/626881/

In the first case Cinder gets request about a specific snapshot straight away. Not sure where this data comes from, maybe Horizon requests meta from Glance first and finds block_device_mapping meta. Then in the end we can see that Cinder gets a POST request with this snapshot id, and creates a volume from this snapshot, does not touch the image at all (seems so).

In the second case Cinder gets a lot of requests, some for snapshots (but no specific one), and in the end we see a POST request to Cinder without the snapshot id, which causes Cinder to create a new volume not from snapshot but from image, and fail.

Revision history for this message
Dmitry Sutyagin (dsutyagin) wrote :

Also in 1st case the internal URL is used, while in second - public URL. Probably insignificant but may help find where and what is going on.

Revision history for this message
Dmitry Sutyagin (dsutyagin) wrote :

I've made a patch for Horizon (mitaka / MOS 9.0), attached, it resolved the issue. However after I made it I realized that it's better to fix this in Cinder instead of Horizon. I'll try to make a patch for Cinder instead.

Revision history for this message
TommyLike (hu-husheng) wrote :

@dsutyagin, Thanks for pushing this into cinder:)

Revision history for this message
Dmitry Sutyagin (dsutyagin) wrote :

Here is a preliminary patch to Cinder which resolves the issue with volume creation from a 0-byte reference image.

I'll upload it to fuel gerrit for review and create something similar for master branch (although I doubt I'll be able to get it merged, will require unit tests and much more effort to pass scrutiny...)

Revision history for this message
Dmitry Sutyagin (dsutyagin) wrote :
summary: - Create Volume from a snapshot-backed Glance image fails (with Ceph
- backend)
+ Create Volume from a snapshot-backed Glance image fails
summary: - Create Volume from a snapshot-backed Glance image fails
+ Create Volume from a 0-byte reference (block_device_mapping) Glance
+ image fails
Revision history for this message
Denis Meltsaykin (dmeltsaykin) wrote :

I'm setting importance to Low because there is a bunch of workarounds and the issue doesn't brake workloads.

Changed in mos:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.