[Starlingx-discuss] [cinder] Analysis of patch c45bb0e for StartlingX upstreaming

Mihai, Irina Irina.Mihai at windriver.com
Mon Nov 26 17:24:47 UTC 2018


Hi Liang,

This patch was covering the scenario when we're trying to create multiple volumes from image at the same time.
In this situation, multiple downloads/convertions would be allowed to start since there would still be conversion space left, but eventually the operation would fail because of the disk being full. This is not caught by any of the "ImageTooBig" or "ImageUnacceptable" exceptions.

Could you please help to address one doubt: why image is converted in the same location with image itself? This patch is to create a volume from image, right?
Right, but I'm not aware of the reasoning behind this. However, if the used image is qcow2 then it needs to be converted to raw before being saved to the volume.

Please let me know if I can help in any other way.

Thanks,
Irina

________________________________
From: Fang, Liang A [liang.a.fang at intel.com]
Sent: Sunday, November 25, 2018 11:44 AM
To: Mihai, Irina
Cc: 'starlingx-discuss at lists.starlingx.io'
Subject: [Starlingx-discuss] [cinder] Analysis of patch c45bb0e for StartlingX upstreaming

Hi Irina

Code review: https://review.openstack.org/#/c/618976/

I’m working of upstreaming this patch. Could you please help to address one doubt: why image is converted in the same location with image itself? This patch is to create a volume from image, right?

I take a look of related code, the destination location would be the newly created volume and the source location is configured in cinder.conf, something like:
image_conversion_dir = /mnt/d100m/image_conversion_dir

I did an experiment, in the latest master branch of cinder upstream repo:

-          If image_conversion_dir has no space to store the downloading image, the exception ImageTooBig will be caught in the beginning of _create_from_image_cache_or_download().

-          If has space to store the image, but dest volume size is smaller than image’s virtual size, an exception “ImageUnacceptable” will raised by check_virtual_size.
So it seems no chance to go to the situation this patch aimed to solve.

Could you please help to give more background of this patch? Or if you think this patch is invalid now, please just tell me, I will mark this patch as abandoned.

Thanks
Liang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20181126/66c0e868/attachment.html>


More information about the Starlingx-discuss mailing list