Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1563299 - upload tickets have only [“write”] ops, so reading from the image will fail
upload tickets have only [“write”] ops, so reading from the image will fail
Status: CLOSED CURRENTRELEASE
Product: ovirt-imageio
Classification: oVirt
Component: General (Show other bugs)
1.1.0
Unspecified Unspecified
unspecified Severity medium
: ovirt-4.2.3
: ---
Assigned To: Nir Soffer
Avihai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2018-04-03 10:29 EDT by Daniel Erez
Modified: 2018-05-10 02:33 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-05-10 02:33:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.2+
ylavi: exception+


Attachments (Terms of Use)
upload_put_get_combined_script (5.74 KB, text/x-python)
2018-04-22 06:55 EDT, Avihai
no flags Details
used_script (5.80 KB, text/x-python)
2018-04-22 09:01 EDT, Avihai
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 89733 None None None 2018-04-03 10:29 EDT

  None (edit)
Description Daniel Erez 2018-04-03 10:29:02 EDT
Tickets support either "write" or "read" ops. Hence, an upload ticket can't be used for reading from the image. 

A few suggested solutions:
- in daemon, "write" ops implies "read": https://gerrit.ovirt.org/#/c/89733/
- in daemon, support tickets with both "read" and "write" capabilities:
  - in engine, add "read" ops to upload tickets.
  - or, add a new UploadDownload constant to ImageTransferDirection enum.
Comment 1 Avihai 2018-04-22 04:46:07 EDT
Hi Daniel,

Can you please provide a clear scenario in order to verify this bug .
Comment 2 Daniel Erez 2018-04-22 06:23:39 EDT
(In reply to Avihai from comment #1)
> Hi Daniel,
> 
> Can you please provide a clear scenario in order to verify this bug .

This change means that an image transfer, created with direction upload, also supports random chunks download. This was specifically required to support qcow2 in virt-v2v integration (which uses qemu-img that needs to read the qcow2 header before writing).
For verification:
* Create a new image transfer with 'types.ImageTransferDirection.UPLOAD'.
* Use PUT requests to upload data.
* Use GET requests to download data.
Both directions should be permitted.
Comment 3 Avihai 2018-04-22 06:55:15 EDT
(In reply to Daniel Erez from comment #2)
> (In reply to Avihai from comment #1)
> > Hi Daniel,
> > 
> > Can you please provide a clear scenario in order to verify this bug .
> 
> This change means that an image transfer, created with direction upload,
> also supports random chunks download. This was specifically required to
> support qcow2 in virt-v2v integration (which uses qemu-img that needs to
> read the qcow2 header before writing).
> For verification:
> * Create a new image transfer with 'types.ImageTransferDirection.UPLOAD'.
> * Use PUT requests to upload data.
> * Use GET requests to download data.
> Both directions should be permitted.

So in the current upload script for each PUT request I need to add a GET request as well , can you please provide with an example script ?

I appended a script executing upload with PUT & GET, will this do ?
Comment 4 Avihai 2018-04-22 06:55 EDT
Created attachment 1425294 [details]
upload_put_get_combined_script
Comment 5 Daniel Erez 2018-04-22 07:01:35 EDT
(In reply to Avihai from comment #3)
> (In reply to Daniel Erez from comment #2)
> > (In reply to Avihai from comment #1)
> > > Hi Daniel,
> > > 
> > > Can you please provide a clear scenario in order to verify this bug .
> > 
> > This change means that an image transfer, created with direction upload,
> > also supports random chunks download. This was specifically required to
> > support qcow2 in virt-v2v integration (which uses qemu-img that needs to
> > read the qcow2 header before writing).
> > For verification:
> > * Create a new image transfer with 'types.ImageTransferDirection.UPLOAD'.
> > * Use PUT requests to upload data.
> > * Use GET requests to download data.
> > Both directions should be permitted.
> 
> So in the current upload script for each PUT request I need to add a GET
> request as well , can you please provide with an example script ?
> 
> I appended a script executing upload with PUT & GET, will this do ?

looks ok, just no need to loop over all chunks, a single chunk is enough for checking.
Comment 6 Avihai 2018-04-22 09:00:45 EDT
Verified at ovirt-imageio-proxy-1.3.0, ovirt-imageio-daemon-1.3.0.

Both PUT & GET works well with 1.3 imageio proxy/daemon, from image-proxy.log:

Thread-3  ) INFO 2018-04-22 15:56:30,957 web:95:web:(log_start) START [10.35.4.178] GET /images/8d97b711-f517-456c-a641-b37a5b138b06
(Thread-3  ) INFO 2018-04-22 15:56:30,959 connectionpool:735:requests.packages.urllib3.connectionpool:(_new_conn) Starting new HTTPS connection (1): storage-ge8-vdsm3.scl.lab.tlv.redhat.com
(Thread-3  ) INFO 2018-04-22 15:56:30,995 web:102:web:(log_finish) FINISH [10.35.4.178] GET /images/8d97b711-f517-456c-a641-b37a5b138b06: [200] 11811160064 (0.04s)
Comment 7 Avihai 2018-04-22 09:01 EDT
Created attachment 1425326 [details]
used_script
Comment 8 Sandro Bonazzola 2018-05-10 02:33:51 EDT
This bugzilla is included in oVirt 4.2.3 release, published on May 4th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.3 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.

Note You need to log in before you can comment on or make changes to this bug.