Description of problem: Currently, when uploading a QCOW image, there is a verification for that image at the end of the process. The verification verifies that the QCOW fits the storage, among other things. This verification actually inspects the QCOW header, which is the first chunk that is being uploaded. Therefor, it can be done also at the start of the upload, so if the QCOW is not valid, the upload will fail at the beginning instead at the end of the process, saving time for the user, and generally making a better UX. Steps to Reproduce: 1. Upload a not-valid QCOW file (e.g, a file which is not QCOW at all.) Actual results: The file being fully uploaded, and only then the upload fails. Expected results: The upload need to fail after a short amount of time.
Tentatively targetting to 4.0
Since we did not implement this the engine yet, I think we should implement this on the client side first, see bug 1357548.
Failing in the backend is relevant to upload via REST - however it is not clear how this can work. When uploading via REST, we are not controlling the order or the size the chunks. The user may send the entire image in one chunk, or send multiple requests (e.g. one request from 0 to size/2, second request from size/2 to end). Another case is resuming an upload, the user may send the last part of the image, keeping the original header on storage. In this case there is no way to verify the image properties before the user tell us to finalize the upload. We can always validate the current header of the image, regardless of what the user uploaded, but we need to know when the image is ready for verification - maybe we can add an api to verify the image, so the user can trigger this verification itself, saving pointless upload.
After having Bug 1357548, I don't see the point implementing this: - The webadmin will block an image with a wrong type before even starting the upload process. - upload using API doesn't guarantee the order of the chunks chosen to upload, so the engine can't know when to verify it. Theoretically the header of the image can be the last part of the upload being made. Allon, any rejections for closing this bug?
(In reply to Amit Aviram from comment #4) > After having Bug 1357548, I don't see the point implementing this: > > - The webadmin will block an image with a wrong type before even starting > the upload process. > > - upload using API doesn't guarantee the order of the chunks chosen to > upload, so the engine can't know when to verify it. Theoretically the header > of the image can be the last part of the upload being made. > > Allon, any rejections for closing this bug? Agreed, closing.