Bug 1042640

Summary: [RFE][neutron]: vlan to tenant mapping is broken
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: RFEsAssignee: RHOS Maint <rhos-maint>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: markmc, yeylon
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/neutron/+spec/vlan2tenant-mapping
Whiteboard: upstream_milestone_none upstream_status_unknown upstream_definition_obsolete
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-19 17:38:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description RHOS Integration 2013-12-13 00:35:35 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/neutron/+spec/vlan2tenant-mapping.

Description:

The relationship between networks/tenants and vlans in OpenStack networking needs to be redone in general.
At the moment it enables to define private networks on different VLANs and assign them to tenants.

As at the moment quantum seems to support only one network device (eth or bond) for alle networks that's okay ... 
... as long as no 2 or more networks are using the same VLAN-ID.

The Problem here is a parent<>child relationship mismatch on bridge level.

If a private network get's assigned to a VM then the Hypervisor Host creates a bridge for the private network on the private networks's VLAN-ID. 
If another private network on the same VLAN get's assigned to a VM on the same host, OpenStack will try to create a new bridge and add the same VLAN device to it, which is not possible and fails.

It is at the moment not possible to use multiple networks on the same VLAN - which is quite common in large network installations.


Specification URL (additional information):

None