Bug 1042579

Summary:	[RFE][neutron]: Model VLAN ports
Product:	Red Hat OpenStack	Reporter:	RHOS Integration <rhos-integ>
Component:	RFEs	Assignee:	RHOS Maint <rhos-maint>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	markmc, yeylon
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
URL:	https://blueprints.launchpad.net/neutron/+spec/model-vlan-ports
Whiteboard:	upstream_milestone_none upstream_status_unknown upstream_definition_superseded
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-19 17:11:30 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:24:41 UTC

Cloned from launchpad blueprint https://blueprints.launchpad.net/neutron/+spec/model-vlan-ports.

Description:

With bare metal nova we cannot add or remove ethernet cards in response to user network requests. We can however give nodes access to additional L2 networks using VLANs.

For triple-o, running openstack on openstack, we want VLANs as well to partition operator and tenant traffic more thoroughly.

In both cases we need to be able to hand information to the instance which will be booting and have only native-VLAN access [but that is sufficient to access the metadata service].

There are multiple options:
 - brute force try all VLAN tags. This may trigger NIDS on some switches, and is slow. [And apparently patented...]
 - bake VLAN config into the image. This is poor for heterogeneous environments and for bare metal non-operator use.
 - use LLDP http://en.wikipedia.org/wiki/LLDP-MED#LLPD-MED - but this is fairly new and may not be supported on all 802.1q capable switches. (So we'd need multiple variants...)
 - Export information about VLANs for the instance via the nova metadata service, then the instance can query that over the native VLAN and self-configure from there.
 - Encode the configured VLAN's into a DHCP vendor option

The last option - DHCP vendor options - was the preferred one in the summit session

Specification URL (additional information):

https://etherpad.openstack.org/HavanaBareMetalVLAN