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 1061193 - Network label name should not be used when associated with the Neutron
Summary: Network label name should not be used when associated with the Neutron
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-webadmin
Version: 3.4
Hardware: x86_64
OS: Linux
Target Milestone: ---
: 3.5.0
Assignee: Lior Vernia
QA Contact: GenadiC
Whiteboard: network
Depends On:
Blocks: 1063716
TreeView+ depends on / blocked
Reported: 2014-02-04 14:29 UTC by GenadiC
Modified: 2016-02-10 19:38 UTC (History)
11 users (show)

Fixed In Version: ovirt-3.5.0-alpha1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-10-17 12:44:19 UTC
oVirt Team: Network

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
oVirt gerrit 26852 master MERGED webadmin: Add InfoIcon for external network label meaning Never
oVirt gerrit 26857 master MERGED webadmin: Introduce ListModelSuggestBoxOnlyEditor Never

Description GenadiC 2014-02-04 14:29:39 UTC
Description of problem:
Network label has different meaning when used with Neutron or used with RHEVM.
In order to differentiate between 2 it should be changed according to the context with which it is used

Version-Release number of selected component (if applicable):

Actual results:
The same label name - "Network label" for RHEVM and Neutron Networks

Expected results:
Different names according to the context

Additional info:

Comment 1 GenadiC 2014-02-05 14:41:26 UTC
Network label in the Ovirt/RHEVM context is a way to update labeled interfaces on the Host with the labeled network instead of using setupNetwork. On the other hand Network label in Neutron context could be a way of labeling specific range of VLANs, so you can have several labels for several VLAN ranges and it has nothing to do with mapping network to Host interfaces an with Ovirt case

Comment 2 Itamar Heim 2014-02-09 08:52:53 UTC
Setting target release to current version for consideration and review. please
do not push non-RFE bugs to an undefined target release to make sure bugs are
reviewed for relevancy, fix, closure, etc.

Comment 3 Mike Kolesnik 2014-02-25 13:04:18 UTC
Nir, do you think its is the same or different?

In my view label in Neutron is the same as in oVirt, telling you which network device to use for the VLAN VM networks. The only difference is that neutron label is restricting the VLAN range, while oVirt label currently has no such restriction, but I don't think it merits a different definition.

Comment 4 Nir Yechiel 2014-02-25 15:19:14 UTC
In this specific case, where the network is created on an external provider and the tenant_network_type is vlan, we are using the "label" to create the mapping to the physical network. So I agree with Mike that the concept is generally similar to oVirt Network Labels feature. That said, the "label" itself in this case is not controlled/configured by oVirt, but from Neutron (plugin.ini). 

My advice is to add a tool-tip to describe the use of Network Label specifically where the logical network is created on external provider, i.e., when "Create on external provider" is checked. This should provide a clearer UX for now, at least until we will conclude our full deployment and configuration solution for Neutron.

Comment 5 Sandro Bonazzola 2014-03-04 09:30:06 UTC
This is an automated message.
Re-targeting all non-blocker bugs still open on 3.4.0 to 3.4.1.

Comment 6 Sandro Bonazzola 2014-05-08 13:56:29 UTC
This is an automated message.

oVirt 3.4.1 has been released.
This issue has been retargeted to 3.5.0 since it has not been marked as high priority or severity issue, please retarget if needed.

Comment 7 GenadiC 2014-06-24 14:25:58 UTC
Verified in 3.5.0-0.0.master.20140605145557.git3ddd2de.el6

Comment 8 Sandro Bonazzola 2014-10-17 12:44:19 UTC
oVirt 3.5 has been released and should include the fix for this issue.

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