Bug 1317253

Summary:	[RFE] Disk image uploader in the GUI
Product:	[oVirt] ovirt-engine	Reporter:	Yaniv Lavi <ylavi>
Component:	RFEs	Assignee:	Amit Aviram <aaviram>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Natalie Gavrielov <ngavrilo>
Severity:	low	Docs Contact:
Priority:	high
Version:	3.6.0	CC:	aaviram, acanan, amureini, bkorren, blaster, bmcclain, bugs, derez, dfediuck, didi, gklein, iheim, jbelka, lveyde, mgoldboi, rbalakri, rjones, sbonazzo, scohen, srevivo, stirabos, trichard, ykaul, ylavi
Target Milestone:	ovirt-4.0.2	Keywords:	FutureFeature, UserExperience
Target Release:	4.0.2.4	Flags:	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+
Hardware:	All
OS:	All
URL:	http://www.ovirt.org/develop/release-management/features/image-upload/
Whiteboard:
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 14:28:21 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:	1337077, 1357269
Bug Blocks:	748288, 1049604, 1091377, 1122970, 1319758, 1360991, 1371738

Description Yaniv Lavi 2016-03-13 11:24:58 UTC

+++ 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 11:26:49 UTC

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 09:54:31 UTC

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 12:40:18 UTC

Amit, where is the doctext handled?

Comment 5 Natalie Gavrielov 2016-07-06 11:45:24 UTC

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 14:18:47 UTC

(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 14:22:31 UTC

(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 14:28:41 UTC

(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 17:58:27 UTC

Admin guide bug - Missing documentation on importing certificate authority:
Bug 1353293

Comment 10 Yedidyah Bar David 2016-07-07 05:55:12 UTC

(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 13:50:59 UTC

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 13:51:08 UTC

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 07:45:41 UTC

(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 12:02:41 UTC

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.