Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1344285

Summary:	Fail fast on not-valid QCOW image upload
Product:	[oVirt] ovirt-engine	Reporter:	Amit Aviram <aaviram>
Component:	Backend.Core	Assignee:	Amit Aviram <aaviram>
Status:	CLOSED WONTFIX	QA Contact:	Natalie Gavrielov <ngavrilo>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	future	CC:	amureini, bugs, nsoffer, ylavi
Target Milestone:	---	Flags:	sbonazzo: ovirt-4.0.z-
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-08-18 12:12:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Amit Aviram 2016-06-09 10:39:13 UTC

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.

Comment 1 Allon Mureinik 2016-06-09 10:59:32 UTC

Tentatively targetting to 4.0

Comment 2 Nir Soffer 2016-07-24 13:58:28 UTC

Since we did not implement this the engine yet, I think we should implement this
on the client side first, see bug 1357548.

Comment 3 Nir Soffer 2016-07-24 14:12:53 UTC

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.

Comment 4 Amit Aviram 2016-08-18 11:39:15 UTC

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?

Comment 5 Allon Mureinik 2016-08-18 12:12:20 UTC

(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.