Cloned from launchpad blueprint https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks. Description: Enable creation of VLAN transparent networks, a major blocker for NFV use cases Specification URL (additional information): None
Two specs were filed for Kilo trying to address the VLAN trunk into a VM use case. This one that got approved is talking only about the ability to flag (in the network API) a network to indicate that a transparent transport is required. Other blueprints propose solutions to decomposing trunks into networks from its individual VLANs, address management on trunk networks (i.e., using sub-ports), and so on. This makes no attempt to address anything other than the simple L2 properties of networks. This spec addresses different use cases to those that deal with management of ports by OpenStack - specifically, the case where two VLAN-aware VMs wish to talk to each other over a number of VLANs, possibly with tags that change over time, and without informing OpenStack at each stage of which VLANs and addresses are in use. This solution is not compatible with current Open vSwitch implementation, and does not seem to address any specific implementation other than the API change.
Feature still not available in OVS. Unable to test API changes.
Verified in # rpm -qa |grep openstack-neutron openstack-neutron-common-2015.1.0-12.el7ost.noarch openstack-neutron-ml2-2015.1.0-12.el7ost.noarch openstack-neutron-fwaas-2015.1.0-3.el7ost.noarch openstack-neutron-2015.1.0-12.el7ost.noarch openstack-neutron-openvswitch-2015.1.0-12.el7ost.noarch [root@puma15 ~(keystone_admin)]# The new code exist
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. https://access.redhat.com/errata/RHEA-2015:1548