virt-sparsify checks to see if there is enough space using an estimate based on the virtual size of the disk (40G in our case). The actual size is substantially smaller.
In the past we didn't specify a --check-tmpdir option, so it defaulted to "warn". This would cause the virt-sparsify command (launched from a shell block in the image building playbook) to hang forever waiting for an carriage return to acknowledge the warning. This was difficult to debug without really digging into process trees :)
We put in a change (over a month ago now) that makes virt-sparsify fail early with messaging (--check-tmpdir fail) instead of hanging forever. This is/was the right thing to do. That said, in my specific case it's a bit overeager, as my typical virthosts in the jenkins farm are low enough on space that they are failing cleanly and in an informative way (good), but in this specific case would build the image successfully. I have disks with ~38.5 GB free, only ~4GB is needed to sparsify the overclound image, and virt-sparsify is using 40G for it's estimate and failing.
This issue tracks replacing the hard coded "fail" param with {{ variable }} that defaults to the safe/informative/overzealous choice ("fail") while allowing the more pragmatic choice for scenarios like ours, where we are limited by the realities of an existing farm of build slaves and know we have space. I also think that this option should disallow (or at least print a warning message) if "warn" is given, as in the current implementation this has the potential to hang forever...it never times out.
virt-sparsify checks to see if there is enough space using an estimate based on the virtual size of the disk (40G in our case). The actual size is substantially smaller.
In the past we didn't specify a --check-tmpdir option, so it defaulted to "warn". This would cause the virt-sparsify command (launched from a shell block in the image building playbook) to hang forever waiting for an carriage return to acknowledge the warning. This was difficult to debug without really digging into process trees :)
We put in a change (over a month ago now) that makes virt-sparsify fail early with messaging (--check-tmpdir fail) instead of hanging forever. This is/was the right thing to do. That said, in my specific case it's a bit overeager, as my typical virthosts in the jenkins farm are low enough on space that they are failing cleanly and in an informative way (good), but in this specific case would build the image successfully. I have disks with ~38.5 GB free, only ~4GB is needed to sparsify the overclound image, and virt-sparsify is using 40G for it's estimate and failing.
This issue tracks replacing the hard coded "fail" param with {{ variable }} that defaults to the safe/informative/overzealous choice ("fail") while allowing the more pragmatic choice for scenarios like ours, where we are limited by the realities of an existing farm of build slaves and know we have space. I also think that this option should disallow (or at least print a warning message) if "warn" is given, as in the current implementation this has the potential to hang forever...it never times out.
Details on virt-sparsify: http://libguestfs.org/virt-sparsify.1.html
Check if "TMPDIR" or --tmp directory has enough space to complete the operation. This is just an estimate.
--check-tmpdir ignore --check-tmpdir continue --check-tmpdir warn --check-tmpdir fail
Proposed patch coming shortly.