Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1083138 - Hide create/remove bond button while interfaces are managed [NEEDINFO]
Summary: Hide create/remove bond button while interfaces are managed
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-node
Version: 3.5.0
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ---
: 3.5.0
Assignee: Ryan Barry
QA Contact: Virtualization Bugs
URL:
Whiteboard: node
Depends On: 1128033
Blocks: 1123329 rhev3.5beta 1156165
TreeView+ depends on / blocked
 
Reported: 2014-04-01 14:32 UTC by Martin Pavlik
Modified: 2016-02-10 20:07 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-11 20:55:03 UTC
oVirt Team: Node
Target Upstream Version:
fdeutsch: needinfo? (mrao)
ecohen: needinfo? (ehildesh)


Attachments (Terms of Use)
screenshot 1 (deleted)
2014-04-01 14:32 UTC, Martin Pavlik
no flags Details
screen-shot and mock-up: current state vs. suggestion (deleted)
2014-04-24 20:43 UTC, Einav Cohen
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2015:0160 normal SHIPPED_LIVE ovirt-node bug fix and enhancement update 2015-02-12 01:34:52 UTC
oVirt gerrit 26339 master MERGED Remove, don't disable, bond creation button when managed Never

Description Martin Pavlik 2014-04-01 14:32:16 UTC
Created attachment 881376 [details]
screenshot 1

Description of problem:
If RHEV-H gets added to RHEV-M its NICs become managed and can be controlled only via RHEV-M not TUI. 

While interfaces are managed create/remove bond button becomes red and cannot be pressed. It would be more intuitive if the button was hidden instead of changing its color to red. 

Version-Release number of selected component (if applicable):
Red Hat Enterprise Virtualization Hypervisor release 6.5 (20140320.0.el6ev)

How reproducible:
100%

Steps to Reproduce:
1. Add RHEV-H to RHEV-M
2. RHEV-H TUI -> Network -> Available System NICs

Actual results:
While interfaces are managed create/remove bond button becomes red and cannot be pressed.

Expected results:
It would be more intuitive if the button was hidden instead of changing its color to red.

Additional info:

Comment 1 Fabian Deutsch 2014-04-01 15:20:39 UTC
Yes, removing buttons that can modify the network configuration is correct when we are managed.

Comment 2 Fabian Deutsch 2014-04-23 14:19:27 UTC
Hey Einav,

can you say if it's better to remove/hide a button when that functionality shall not be offered, or if it just shall be disabled.

Comment 3 Einav Cohen 2014-04-24 20:43:42 UTC
Created attachment 889437 [details]
screen-shot and mock-up: current state vs. suggestion

Comment 4 Einav Cohen 2014-04-24 20:46:59 UTC
(In reply to Fabian Deutsch from comment #2)
> Hey Einav,
> 
> can you say if it's better to remove/hide a button when that functionality
> shall not be offered, or if it just shall be disabled.

Hi Fabian,

Typically, a button should be disabled rather than hidden in case there is some added value in showing the user that button and/or if the user is expecting to see this button. 

I assume that there are scenarios in which this button is enabled (e.g. configuring a brand new RHEV-H machine, rather than re-configuring an existing RHEV-H machine that was already added to RHEV-M or something similar?). 
Question is if in the scenario in which creating a bond is impossible (e.g. since all NICs are managed), the user may still want to create a bond / may expect to be able to create a bond. If so, keeping the button is probably better, but probably only with a proper explanation. 
Pointing out that the red color of the disabled button really stands out, so at least to me - it doesn't seem like a disabled option. Not sure if there is any TUI convention for disabled buttons, but personally - I would recommend going with a light gray color for disabled buttons. 
See attachment 889437 [details] for the current state vs. my recommendation (the exact phrasing can be tweaked as needed, of course), assuming we want to keep the button displayed, but disabled. 

If we expect the user to not want to create bonds in this context, or if we expect that a typical user would easily understand that 'Managed' NICs mean that network configurations such as bond creation should be done via RHEV-M - hiding the button is a better option IMO. 

Needinfo'ing Malini/Eldan for comments/alternative suggestions.

Comment 5 Fabian Deutsch 2014-04-25 11:59:35 UTC
Hi Einav,

thanks for you comments.
I agree that the color selection is suboptimal, and we should address this to better visualize enabled and disabled items.

About now hiding or disabling the bonds button - I am not sure what the expectation is here. Maybe we should have a general message telling that the network configuration is expected to happen through the manager, when registered.

Comment 6 Fabian Deutsch 2014-07-24 16:02:55 UTC
This is a mass change, moving bugs of merged patches into MODIFIED.

Please correct the state, if you think that the move was not justified.

Comment 8 Martin Pavlik 2014-09-10 06:27:08 UTC
@Ryan 
is there a working image to test this?

Comment 9 Ying Cui 2014-09-10 07:07:27 UTC
Martin, rhev-hypervisor7-7.0-20140904.0 in brew yet, but this bug is blocked by 
Bug 1128033 - [vdsm-reg el7]rhevh7.0 for rhev 3.5 build register to RHEV-M 3.5 failed.

you can verify this bug after bug 1128033 fixed.

Comment 10 Yaning Wang 2014-12-18 02:57:28 UTC
Tested on:

RHEV-H 6.6-20141212.0.el6ev
ovirt-node-3.1.0-0.34.el6


Test steps:

1. clean install rhevh
2. add rhevh into RHEV-M 3.5.0-0.25.el6ev
3. all nic in managed status
4. "create/remove bond button" is invisible

Comment 12 errata-xmlrpc 2015-02-11 20:55:03 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

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

https://rhn.redhat.com/errata/RHEA-2015-0160.html


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