Comment 3 for bug 1661328

Jay: Yes we indeed have a workaround we are trying to implement. The first step is figuring out there is not enough space for the file.

Félix's first commit is a workaround that will allow us to find out the size of the image. Our next step is doing a fallocate with the file size when writing to the file. This should raise when the disk is not big enough.

We thought about the different solutions and found the following:
* Feed the image URL directly to qemu-img. The tool will issue "Range" requests to the HTTP server. This will not allow checksum verification and is considered a regression for us.

* Use RAW images with streaming (we have a unique set of qcow2 images for both virtual and metal cloud which we wouldn't like to duplicate)

* Use Glare to store multiple image types and integrate Ironic to request the most appropriate image type

* Use iSCSI drivers to stream any kind of image to disk instead of using node memory (our conductors have restricted access to the nodes, both in terms of network access and bandwidth, pushing image data through the management network would be a step backward for us)

We settled on the following solution:
* Download image to a loop device backed by the actual disk drive (with an offset). Keep existing code and benefit from checksumming already present.

We wrote a POC of that solution and it works wonderfully. Despite an additional write+read on disk, it takes about the same time as normal deployment. This is probably due to hard disk caching.