Bug 1059249 - When openstack/neutron is installed with vlan range 200-300 and ovirt user creates network with VLAN 10, the action succeeds
Summary: When openstack/neutron is installed with vlan range 200-300 and ovirt user cr...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-core
Version: 3.4
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
: 3.5.0
Assignee: Moti Asayag
QA Contact: GenadiC
URL:
Whiteboard: network
Depends On:
Blocks: 1063716
TreeView+ depends on / blocked
 
Reported: 2014-01-29 13:42 UTC by GenadiC
Modified: 2016-02-10 19:37 UTC (History)
12 users (show)

Fixed In Version: ovirt-3.5.0-beta2
Clone Of:
Environment:
Last Closed: 2014-10-17 12:32:18 UTC
oVirt Team: Network
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 30005 0 master MERGED engine: External network with vlan must be labeled Never
oVirt gerrit 30491 0 ovirt-engine-3.5 MERGED engine: External network with vlan must be labeled Never

Description GenadiC 2014-01-29 13:42:31 UTC
Description of problem:
If you create range 200-300 on Neutron and create a network with VLAN 10 the action succeeds

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


How reproducible:
Always

Steps to Reproduce:
1. Create external network from Ovirt
2. Pick up a VLAN 10 for that vlan when the Vlan range on Neutron is 200-300
3.

Actual results:
The network is created with VLAN 200 on Neutron

Expected results:
The action should be blocked because incorrect VLAN (not from the range) was picked up

Additional info:

Comment 1 Ofer Blaut 2014-01-30 06:20:09 UTC
It seems like API is using tenant networks, instead of using provider network.

Provider network has the ability to specify the exact VLAN from RHEV into Neutron.

In case the VLAN is not in the range the API return error , and network creations MUST fail


Moving severity to HIGH, since if user create network with VLAN 10 and actually it is not created to NO network at all ( don't forget the switchs on the way are configured to allow specific range of vlans on hosts )

Comment 2 Itamar Heim 2014-02-02 08:17:06 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 Assaf Muller 2014-02-09 13:08:23 UTC
I think for starters, when creating an external network with a VLANs based network provider, we should hide / disable the VLAN field. Later, we can consider the creation of provider networks, and enhance the GUI so that it is more clear and understandable.

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

Comment 5 Mike Kolesnik 2014-03-12 11:57:49 UTC
The label must be specified when user selects a specific VLAN ID.

A user might, however, choose a label but not a specific VLAN ID.

Comment 6 GenadiC 2014-07-27 07:14:52 UTC
Verified in 3.5.0-0.0.master.20140722232058.git8e1babc.el6

Comment 7 Sandro Bonazzola 2014-10-17 12:32:18 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.