Bug 1360192
| Summary: | [RFE] Image uploader: resume upload - user is asked to supply source, path and image type - all over again | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Natalie Gavrielov <ngavrilo> | ||||
| Component: | BLL.Storage | Assignee: | Daniel Erez <derez> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Natalie Gavrielov <ngavrilo> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 4.0.2 | CC: | acanan, amureini, apinnick, bugs, derez, ngavrilo, ratamir, tnisan, ylavi | ||||
| Target Milestone: | ovirt-4.2.0 | Keywords: | FutureFeature | ||||
| Target Release: | 4.2.0 | Flags: | rule-engine:
ovirt-4.2?
ylavi: ovirt-4.3? ratamir: testing_plan_complete+ ylavi: planning_ack? rule-engine: devel_ack+ rule-engine: testing_ack+ |
||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Enhancement | |||||
| Doc Text: |
Resuming a paused image download no longer requires selecting the file again, unless the browser has been restarted.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2017-12-20 10:49:34 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: | |||||||
| Bug Depends On: | 1388970 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
Unfortunately, Browsers do not allow choosing files automatically by code due to security reasons, so we can't save the chosen file after starting the upload session and set it again when resuming.. Image type is going to be automatically deduced when Bug 1357548 will be modified, so we are left with only file selection. So the best we can do is to tip the user what was the recent path that was selected. it can be done by adding some tool tip, or a label in the dialog. Thoughts? (In reply to Amit Aviram from comment #2) > Unfortunately, Browsers do not allow choosing files automatically by code > due to security reasons, so we can't save the chosen file after starting the > upload session and set it again when resuming.. > > Image type is going to be automatically deduced when Bug 1357548 will be > modified, so we are left with only file selection. > > So the best we can do is to tip the user what was the recent path that was > selected. it can be done by adding some tool tip, or a label in the dialog. > > Thoughts? Well, besides the fact it looks very strange when we request from the user to select once again the disk to be uploaded.. what's going to happen when the user selects a different disk.. not the one he chose at the beginning? (In reply to Natalie Gavrielov from comment #3) > (In reply to Amit Aviram from comment #2) > > Unfortunately, Browsers do not allow choosing files automatically by code > > due to security reasons, so we can't save the chosen file after starting the > > upload session and set it again when resuming.. > > > > Image type is going to be automatically deduced when Bug 1357548 will be > > modified, so we are left with only file selection. > > > > So the best we can do is to tip the user what was the recent path that was > > selected. it can be done by adding some tool tip, or a label in the dialog. > > > > Thoughts? > > Well, besides the fact it looks very strange when we request from the user > to select once again the disk to be uploaded.. what's going to happen when > the user selects a different disk.. not the one he chose at the beginning? The file's size is compared with the previously selected one, so if the size is not equal, an error message will appear. Note that this bug also addresses the fact that the user needs to supply the image type.. Right now the default image type that is shown in the drop down list is QCOW2 (a user needs to switch it back to raw, in case it's a raw disk). This means that if a user resumes a Raw image type upload and won't notice this field switched to QCOW2, the upload will continue and when it finishes will turn to status Illegal IMO, image type should be disabled when resuming an upload, there is no reason to leave it enabled.. (In reply to Natalie Gavrielov from comment #5) > Note that this bug also addresses the fact that the user needs to supply the > image type.. > Right now the default image type that is shown in the drop down list is > QCOW2 (a user needs to switch it back to raw, in case it's a raw disk). > This means that if a user resumes a Raw image type upload and won't notice > this field switched to QCOW2, the upload will continue and when it finishes > will turn to status Illegal > IMO, image type should be disabled when resuming an upload, there is no > reason to leave it enabled.. After derez merged https://gerrit.ovirt.org/#/c/61179/, the image type won't be changeable at all, it will be inferred from the file itself. (In reply to Amit Aviram from comment #6) > (In reply to Natalie Gavrielov from comment #5) > > Note that this bug also addresses the fact that the user needs to supply the > > image type.. > > Right now the default image type that is shown in the drop down list is > > QCOW2 (a user needs to switch it back to raw, in case it's a raw disk). > > This means that if a user resumes a Raw image type upload and won't notice > > this field switched to QCOW2, the upload will continue and when it finishes > > will turn to status Illegal > > IMO, image type should be disabled when resuming an upload, there is no > > reason to leave it enabled.. > > After derez merged https://gerrit.ovirt.org/#/c/61179/, the image type won't > be changeable at all, it will be inferred from the file itself. Great! The attached patch is abandoned, setting to NEW. Amit - can you update on the status here? Is there a different patch? An alternative approach? Yes, instead of keeping the file's path (actually, only its name due to JS restrictions) in the DB- which is not very helpful, we will save the file handle in the browser. The code is written, a patch will be pushed soon. This bug depends on a bug fix that is targeted to 4.2, moving to 4.2 as well Added a 'silent' resume support for the browser session. I.e. resuming a download won't require selecting the file again *until restarting the browser* (as the file element is saved in memory). (In reply to Daniel Erez from comment #11) > Added a 'silent' resume support for the browser session. I.e. resuming a > download won't require selecting the file again *until restarting the > browser* (as the file element is saved in memory). Daniel, can we please add some doctext about this? Thanks! Verified using builds: rhvm-4.2.0-0.6.el7.noarch vdsm-4.20.9-1.el7ev.x86_64 This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report. |
Created attachment 1184099 [details] snapshot of resume upload window Description of problem: When resuming an upload, a window appears for selecting source, path and image type, since the user already chose these parameters (at the beginning - to start the upload process) there is no need to show this window again and ask for this data. Version-Release number of selected component: rhevm-4.0.2-0.1.rc.el7ev.noarch How reproducible: 100% Steps to Reproduce: 1. Upload an image 2. Pause upload 3. Resume Actual results: A window for selecting a file appears. Expected results: It should automatically continue with resuming the upload (not request the user to supply info).