Bug 903287 - When creating a network the default network doesn't get chosen.
When creating a network the default network doesn't get chosen.
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal (Show other bugs)
3.2.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 3.2.0
Assigned To: Alona Kaplan
Meni Yakove
network
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-23 11:25 EST by Ohad Basan
Modified: 2016-02-10 14:55 EST (History)
12 users (show)

See Also:
Fixed In Version: SF7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-10 17:43:54 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 11650 None None None Never

  None (edit)
Description Ohad Basan 2013-01-23 11:25:10 EST
Description of problem:
When creating a new nic for a vm instead of chosing the "rhevm" network by default the combo list defaults to an empty network entry.

How reproducible:

always

Steps to Reproduce:
1.create a vm.
2.add new nic
3.
  
Actual results:
Combo list defaults to empty network

Expected results:
in case only one network is available (rhevm for example) the ui should default to it.

Additional info:
Comment 4 Itamar Heim 2013-01-24 05:42:16 EST
please note the rhevm network isn't the "default" one.
it may not be a vm network
user may have no permissions for it.

it make sense to choose the first network the user has permissin to.
(also makes sense to keep their last choice per cluster in a cookie probably)
Comment 5 Alona Kaplan 2013-01-28 10:00:07 EST
If the vm's cluster compatibility version is 3.2, empty network is a valid choice.

There is no special logic for choosing the default network. The first one in the list is the default. In case "empty" network is permitted it is the first in the network list, therefore it is the default.

Do you think there should be a special logic for choosing the default network?
Comment 6 Simon Grinberg 2013-01-28 11:15:35 EST
(In reply to comment #5)
> If the vm's cluster compatibility version is 3.2, empty network is a valid
> choice.
> 
> There is no special logic for choosing the default network. The first one in
> the list is the default. In case "empty" network is permitted it is the
> first in the network list, therefore it is the default.
> 
> Do you think there should be a special logic for choosing the default
> network?

- For sake of backwards compatibility (and the AllInOne) we'll need to keep rhevm if it's defined as VM network.
- If there is only one VM network, then show only that
- If there is more then one, then I would consider to leave the default maybe with a tooltip saying select a network or leave as is to remain detached.
Comment 7 Simon Grinberg 2013-02-06 03:36:48 EST
In the last bug scrubbing meeting the agreement was to sort the list as following:
1. If the management network (rhevm) is VM network is first on the list
2. Sort the rest alphabetically.
3. Default network is always the last.
Comment 8 Alona Kaplan 2013-02-10 08:52:48 EST
(In reply to comment #7)

Clarification of the comment (Got ack from Simon)-
1. The networks list is sorted alphabetically.
2. If the management network is in the list- it should be the default.
   Otherwise, the first network in the list will be the default.
3. Empty network is always the last.
Comment 9 Meni Yakove 2013-02-14 04:22:56 EST
Verified on rhevm-3.2.0-8.el6ev.noarch
Comment 10 errata-xmlrpc 2013-06-10 17:43:54 EDT
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.

http://rhn.redhat.com/errata/RHSA-2013-0888.html

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