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:
Yes, removing buttons that can modify the network configuration is correct when we are managed.
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.
Created attachment 889437 [details] screen-shot and mock-up: current state vs. suggestion
(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.
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.
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.
@Ryan is there a working image to test this?
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.
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
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
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days