Bug 1131508 - [RFE] [engine-webadmin] There should be a separated tag for OVF_STORE disks under the 'Disks' main tab
Summary: [RFE] [engine-webadmin] There should be a separated tag for OVF_STORE disks u...
Keywords:
Status: CLOSED DUPLICATE of bug 1211762
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RFEs
Version: ---
Hardware: x86_64
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: Tal Nisan
QA Contact: Raz Tamir
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-19 12:57 UTC by Elad
Modified: 2016-12-05 13:43 UTC (History)
10 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-12-05 13:42:12 UTC
oVirt Team: Storage
Embargoed:
ylavi: ovirt-future?
ylavi: planning_ack?
ylavi: devel_ack?
ylavi: testing_ack?


Attachments (Terms of Use)

Description Elad 2014-08-19 12:57:50 UTC
Description of problem:

Actual results:

OVF_STORE disks, holding the tar ile that contains the OVF of the storage domain are being created for each storage domain in the setup. The default number of copies for those disks is 2 for each domain. 
The disks are listed under the 'Disks' main tab in UI, under 'Images'. 
In an enterprise env. with a lot of storage domain, those disks, list with the regular disks, cause the disks list to be very big even when there are no regular disks in it. This can be very painful for admins.

Expected results:

OVF_STORE disks shouldn't be listed under the 'Images' tag under 'Disks' main tab. There should be a separated new tag for those disks.

Comment 1 Tal Nisan 2014-08-20 10:00:11 UTC
Liron, you think it's correct to have a separate tag for those? I'm not sure this will be a correct behavior

Comment 2 Liron Aravot 2014-08-26 08:49:28 UTC
Not sure about that. adding needinfo? on einav to see what's her opinion on that (we discussed that a while ago).

Comment 3 Einav Cohen 2014-09-10 17:49:52 UTC
I actually agree with Elad; as I mentioned to Liron during his session on this feature, I think that separating the OVF_STORE disks from the regular virtual-hard-drive disks makes sense here, and we already have the "mechanism" for visually separating different types of disks (i.e. the top-panel radio-button); I think that adding another radio-button for displaying only OVF_STORE images, and filtering out OVF_STORE images from the "Images" radio-button, makes a lot of sense.

Comment 4 Liron Aravot 2014-09-14 07:18:06 UTC
I'm not against having a separation, but i'm not sure that I'd go for another radio button here.
currently the radio button differentiate between different types of disk, LUNs and images. it may be confusing to separate ovf stores from images as the ovf stores ARE images.

Maybe a checkbox or config value (display or not) might suit here.
what do you think?

Comment 5 Einav Cohen 2014-09-20 00:23:55 UTC
IMO - definitely not a config value; 

even though the ovf store ARE images, you need to look at it from the user's perspective: does the user care that the ovf store is an image? or is it just a coincidence since you (developer) decided to implement it that way (i.e. could you theoretically implement ovf stores completely differently)?
in other words: is there a really good reason to display the ovf stores alongside the other "regular" images?
if the answer is "no" - I think that you should go with an extra radio-button. 
otherwise - yes, something like a check-box within the "images" radio-button of "show/hide ovf stores" makes sense here (I suggest contacting Eldan for advice on the exact design).

Comment 6 Tal Nisan 2014-09-21 08:31:29 UTC
We can also make them appear only when the "All" option is selected while obviously not appearing in "Images" and "LUNs"

Comment 7 Einav Cohen 2014-11-04 18:34:49 UTC
(In reply to Tal Nisan from comment #6)
> We can also make them appear only when the "All" option is selected while
> obviously not appearing in "Images" and "LUNs"

though may be more "correct", this may create confusion (see http://lists.ovirt.org/pipermail/users/2014-November/028922.html), please consider carefully.

Comment 8 Yaniv Lavi 2016-12-05 13:42:12 UTC

*** This bug has been marked as a duplicate of bug 1211762 ***


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