Bug 1657977
| Summary: | [UI] Gray out multiQueues check box in Instance Types 'New/Edit' option - make it clear that enabled by default | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Abhishekh Patil <abpatil> |
| Component: | ovirt-engine | Assignee: | Ales Musil <amusil> |
| Status: | CLOSED ERRATA | QA Contact: | Michael Burman <mburman> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.2.7 | CC: | abpatil, danken, dholler, mburman, mtessun, rbarry, rdlugyhe, Rhev-m-bugs |
| Target Milestone: | ovirt-4.3.2 | ||
| Target Release: | 4.3.0 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | ovirt-engine-4.3.2 | Doc Type: | Bug Fix |
| Doc Text: |
Previously, the "Multi Queues enabled" checkbox was missing from the New- or Edit Instance Types window in the Administration Portal. The current release fixes this issue.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-05-08 12:39:09 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Network | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Abhishekh Patil
2018-12-10 21:43:46 UTC
The 'Multi Queues enabled' checkbox is hidden by intention in the Instance Types dialogs. (In reply to Dominik Holler from comment #5) > The 'Multi Queues enabled' checkbox is hidden by intention in the Instance > Types dialogs. I suspect that we have disabled this on the instance type, because we have good defaults which we'd like everybody to use. We still let users disable this on a specific VM, though, on the hopefully-rare occasion that our default is wrong. I believe that we could be visually better if we keep the queues checkbox, but have it disabled, so that it is clearer what the (i)nfo icon refers to. Abhishekh Patil, can you find out if/why does the customer want to modify the number of queues per vNIC? (In reply to Dan Kenigsberg from comment #6) > > I believe that we could be visually better if we keep the queues checkbox, > but have it disabled, so that it is clearer what the (i)nfo icon refers to. > I think this would be more transparent to the user, too. I would also suggest that if we going to disable the queues checkbox, then the blue icon tooltip should say that. It should say that multiqueues are not available via instance type. (In reply to Dan Kenigsberg from comment #6) > (In reply to Dominik Holler from comment #5) > > The 'Multi Queues enabled' checkbox is hidden by intention in the Instance > > Types dialogs. > > I suspect that we have disabled this on the instance type, because we have > good defaults which we'd like everybody to use. We still let users disable > this on a specific VM, though, on the hopefully-rare occasion that our > default is wrong. > > > I believe that we could be visually better if we keep the queues checkbox, > but have it disabled, so that it is clearer what the (i)nfo icon refers to. > > > Abhishekh Patil, can you find out if/why does the customer want to modify > the number of queues per vNIC? It is not about the need of this option, but this option is still available if we edit the VM and navigate to Edit -> Resource Allocation and it not present when checking from Administration -> Instance Types. In the rhvm GUI, if we open the 'edit' UI for a VM and navigate to 'Resource Allocation', under the queues section there is a checkbox labeled 'Multi Queues Enabled', which dictates whether RHEV gives each vNIC a single queue or multiple based on the number of vCPUs available to that VM. Under Administration -> Instance Types, both the create and edit interfaces have an ⓘ hover which displays information about this checkbox, suggesting you should be able to set it for an Instance Type so all VMs created with said type as a basis are correctly configured at creation time. The checkbox itself is missing, however, preventing you from configuring this setting. > It is not about the need of this option... > ... preventing you from configuring this setting. I am confused by your reply. May I ask again: does the customer want to disable this option for the whole instance type? if so, why? (In reply to Dan Kenigsberg from comment #10) > > It is not about the need of this option... > > > ... preventing you from configuring this setting. > > I am confused by your reply. May I ask again: does the customer want to > disable this option for the whole instance type? if so, why? They expecting that this option should exist for the whole instance type. They are trying to create VM using the instance type which has multi queues enabled. (In reply to Abhishekh Patil from comment #11) > (In reply to Dan Kenigsberg from comment #10) > > > It is not about the need of this option... > > > > > ... preventing you from configuring this setting. > > > > I am confused by your reply. May I ask again: does the customer want to > > disable this option for the whole instance type? if so, why? > > They expecting that this option should exist for the whole instance type. > They are trying to create VM using the instance type which has multi queues > enabled. Multi queues are enabled by default, so they would need only to modify the instance type, if they want to disable multi queues. So let's modify the UI in a way, that this would be obvious by showing the checked multi queues option grayed out in the instance type dialogs. So my understanding: - We want to show the multiqueue option in Instance Types but it is greyed out (and ticked). - We do not want customers to change that option in instance types as it is the most sensible default. (C#6) - As hiding the option was intentionally in the first place (C#5) we want to keep this behaviour. - Users can still change the multiqueue option on a per VM basis (and probably on a template basis, too). If that is the case, I am fine with the approach. Verified on - rhvm-4.3.2-0.1.el7.noarch Ales, for the tooltip fix, i reported BZ 1685876 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://access.redhat.com/errata/RHEA-2019:1085 |