Bug 1317253 - [RFE] Disk image uploader in the GUI
[RFE] Disk image uploader in the GUI
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: RFEs (Show other bugs)
3.6.0
All All
high Severity low (vote)
: ovirt-4.0.2
: 4.0.2.4
Assigned To: Amit Aviram
Natalie Gavrielov
http://www.ovirt.org/develop/release-...
: FutureFeature, UserExperience
Depends On: 1337077 1357269
Blocks: 748288 1049604 RHEV_ISO_Uploader_UI 1122970 1319758 1360991 1371738
  Show dependency treegraph
 
Reported: 2016-03-13 07:24 EDT by Yaniv Lavi
Modified: 2016-08-31 02:19 EDT (History)
24 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
With this release, you can use the Admininistration Portal to upload virtual machine disk images and attach them to virtual machines. The uploaded image must be a QEMU-compatible image file that can be connected to QEMU virtual machines. Note that ovirt-imageio-proxy needs to be installed on the Manager for this feature to work.
Story Points: ---
Clone Of: RHEV_ISO_Uploader_UI
Environment:
Last Closed: 2016-08-12 10:28:21 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.0.z+
rule-engine: exception+
ylavi: priority_rfe_tracking+
acanan: testing_plan_complete+
ylavi: planning_ack+
amureini: devel_ack+
acanan: testing_ack+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 57259 None None None 2016-05-15 04:11 EDT
oVirt gerrit 57437 None None None 2016-05-15 04:10 EDT
oVirt gerrit 58258 ovirt-engine-4.0 MERGED engine: change upload ticket "path" to "url" 2016-05-30 08:26 EDT

  None (edit)
Description Yaniv Lavi 2016-03-13 07:24:58 EDT
+++ This bug was initially created as a clone of Bug #1091377 +++

Description of problem:
It would be helpful to be able to upload iso images through the gui.
Being able to add them through the hosted engine and through nfs is fine in many cases of course, but a more integrated solution into the webgui would be great.

Letting users choose their own iso seems a better solution in many cases, especially if it can go under their own resource pool.

First time poster, so please tell me if I'm doing anything incorrectly.

With my best regards
Klas

--- Additional comment from Sean Cohen on 2014-07-24 16:37:32 IDT ---



--- Additional comment from Einav Cohen on 2014-08-04 19:49:01 IDT ---

please see bug 1122970 for graphic design suggestion. thanks.

--- Additional comment from Sandro Bonazzola on 2014-08-13 11:30:39 IDT ---

Moving to storage: it's a change needed in the engine webadmin for importing an image in an iso domain. Doesn't look like an integration task.

--- Additional comment from Allon Mureinik on 2014-08-13 11:40:04 IDT ---

(In reply to Sandro Bonazzola from comment #3)
> Moving to storage: it's a change needed in the engine webadmin for importing
> an image in an iso domain. Doesn't look like an integration task.

I tend to agree.
Sean, let's review?

--- Additional comment from Sean Cohen on 2014-12-22 19:54:50 IST ---

Ack,
Sean

--- Additional comment from Allon Mureinik on 2015-03-24 08:30:24 IST ---



--- Additional comment from Sandro Bonazzola on 2015-09-04 11:59:25 IDT ---

This is an automated message.
This Bugzilla report has been opened on a version which is not maintained anymore.
Please check if this bug is still relevant in oVirt 3.5.4.
If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution)
If it's an RFE please update the version to 4.0 if still relevant.
Comment 1 Yaniv Lavi 2016-03-13 07:26:49 EDT
This bug was created to track the addition of a disk image (not ISO image) upload via the GUI.
Comment 2 Sandro Bonazzola 2016-05-02 05:54:31 EDT
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
Comment 4 Allon Mureinik 2016-06-13 08:40:18 EDT
Amit, where is the doctext handled?
Comment 5 Natalie Gavrielov 2016-07-06 07:45:24 EDT
Hi Amit,

When using the image upload feature, there is a step that needs to be performed - browser side (download certificate and configure the browser to work with it).
A few questions regarding that:
1. Is the feature planned to work that? or is it a workaround meantime?
2. If it is the design, is there documentation for it?
3. If it's not, then when is planned to be fixed?   

Thanks,
Comment 6 Amit Aviram 2016-07-06 10:18:47 EDT
(In reply to Natalie Gavrielov from comment #5)
> Hi Amit,
> 
> When using the image upload feature, there is a step that needs to be
> performed - browser side (download certificate and configure the browser to
> work with it).
> A few questions regarding that:
> 1. Is the feature planned to work that? or is it a workaround meantime?
Unfortunately there's nothing we can do to solve that programmatically.. This is the browser's way to protect its client from security threats..  so yea :)

> 2. If it is the design, is there documentation for it?
We should document it, and regardless improve the UX: Bug 1343878 opened to handle that.

Thanks, Amit
Comment 7 Yedidyah Bar David 2016-07-06 10:22:31 EDT
(In reply to Amit Aviram from comment #6)
> (In reply to Natalie Gavrielov from comment #5)
> > Hi Amit,
> > 
> > When using the image upload feature, there is a step that needs to be
> > performed - browser side (download certificate and configure the browser to
> > work with it).
> > A few questions regarding that:
> > 1. Is the feature planned to work that? or is it a workaround meantime?
> Unfortunately there's nothing we can do to solve that programmatically..
> This is the browser's way to protect its client from security threats..  so
> yea :)

If the cert is signed by the engine ca, importing the engine ca should be enough. Also we should allow signing it with a 3rd party ca, if we don't please open a bug to track this. Thanks.
Comment 8 Amit Aviram 2016-07-06 10:28:41 EDT
(In reply to Yedidyah Bar David from comment #7)
> (In reply to Amit Aviram from comment #6)
> > (In reply to Natalie Gavrielov from comment #5)
> > > Hi Amit,
> > > 
> > > When using the image upload feature, there is a step that needs to be
> > > performed - browser side (download certificate and configure the browser to
> > > work with it).
> > > A few questions regarding that:
> > > 1. Is the feature planned to work that? or is it a workaround meantime?
> > Unfortunately there's nothing we can do to solve that programmatically..
> > This is the browser's way to protect its client from security threats..  so
> > yea :)
> 
> If the cert is signed by the engine ca, importing the engine ca should be
> enough. 
That's the only thing we expect from the user. we just want to add docs and UX to explain it, in case the user didn't import the engine's CA.

> Also we should allow signing it with a 3rd party ca, if we don't
> please open a bug to track this. Thanks.
We use the engine's CA, are you suggesting to use another CA signing specifically for this feature? or generally in oVirt?
Comment 9 Natalie Gavrielov 2016-07-06 13:58:27 EDT
Admin guide bug - Missing documentation on importing certificate authority:
Bug 1353293
Comment 10 Yedidyah Bar David 2016-07-07 01:55:12 EDT
(In reply to Amit Aviram from comment #8)
> (In reply to Yedidyah Bar David from comment #7)
> > If the cert is signed by the engine ca, importing the engine ca should be
> > enough. 
> That's the only thing we expect from the user. we just want to add docs and
> UX to explain it, in case the user didn't import the engine's CA.

Generally speaking, the user is supposed to import into the browser the ca cert also for regular https access to the web admin. If the user does not, the browser will popup allowing the import the apache cert, but not ca cert - this has to be done manually. Does the uploader ui require importing the ca cert? Will the browser not popup allowing to accept just a single cert (which?)?

Anyway, importing the ca cert should imo be documented already. But I now searched and it seems to be broken - pointing at /ca.crt which is deprecated in 4.0:

https://access.redhat.com/documentation/en/red-hat-virtualization/4.0-beta/rhevm-shell-guide/12-tls-ssl-certification

Opened bug 1353441 for this.

> 
> > Also we should allow signing it with a 3rd party ca, if we don't
> > please open a bug to track this. Thanks.
> We use the engine's CA, are you suggesting to use another CA signing
> specifically for this feature? or generally in oVirt?

Generally, oVirt already allows this for the apache cert (but not engine<->hosts ssl comm, which is always signed by the internal ca):

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/appe-Red_Hat_Enterprise_Virtualization_and_SSL.html
Comment 11 Natalie Gavrielov 2016-07-17 09:50:59 EDT
Disk image uploader not working: issue #1357269
Used: http://bob.eng.lab.tlv.redhat.com/builds/4.0/4.0.1-2/el$releasever
Comment 12 Red Hat Bugzilla Rules Engine 2016-07-17 09:51:08 EDT
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Comment 13 Yaniv Kaul 2016-07-18 03:45:41 EDT
(In reply to Natalie Gavrielov from comment #11)
> Disk image uploader not working: issue #1357269
> Used: http://bob.eng.lab.tlv.redhat.com/builds/4.0/4.0.1-2/el$releasever

Moving it to ASSIGNED does not help - the feature is in, various bugs need to be handled. You can add the above BZ as a 'depends on' perhaps.
Comment 16 Natalie Gavrielov 2016-08-07 08:02:41 EDT
Verified:
rhevm-4.0.2.3-0.1.el7ev.noarch
ovirt-imageio-proxy-0.3.0-0.el7ev.noarch
ovirt-imageio-common-0.3.0-0.el7ev.noarch
vdsm-4.18.10-1.el7ev.x86_64
ovirt-imageio-daemon-0.3.0-0.el7ev.noarch


The basic flow:
1. Upload a disk image.
2. Attach the uploaded disk image to a running VM (with OS installed).
3. Mount the uploaded disk
4. Verify content of the uploaded disk is available. 

I've uploaded:
1. CQOW2 disk image on block and file.
2. RAW disk on block and file.

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