Similarly, the documentation should describe the openvswitch agent's bridge_mappings variable and the linuxbridge agent's physical_interface_mappings variable. These need to be configured correctly on each node, along with tenant_network_type and network_vlan_ranges on the server, in order for quantum networking to function.

I really need more information on what "correct" means for these configuration values.

The tenant_network_type and network_vlan_ranges configuration keys are now covered albeit briefly. Still need to find some source material for:

bridge_mappings
physical_interface_mappings

I sent the following to Steve in response to email indicating "physical_network" needed better explanation. Please let me know if additional info is needed.


The term "physical_network" is encountered by OpenStack admins in three
closely inter-related usages:

A) The left-hand-side of an item in the network_vlan_ranges config
variable used by the openvswitch or linuxbridge plugin on nodes where
quantum-server is deployed.

B) The provider:physical_network attribute of a network whose
provider:network_type is either flat or vlan. Note that this usage
includes networks created as provider networks (specifying the provider
attributes explicitly) and those created as tenant networks (the set of
provider attributes is allocated from a pool).

C) The left-hand-side of an item in either the bridge_mappings config
variable used by quantum-openvswitch-agent or the
physical_interface_mappings config variable used by
quantum-linuxbridge-agent.


The physical_network is a simple string name that associates usages A,
B, and C above. Upstream examples typically use "physnet1", "physnet2",
..., but more meaningful names are likely in deployments (i.e. "VLAN
trunk A" or "DMZ"). The DB schema limits the names to 64 characters.

The only purpose of physical_network is to associate the three above
usages of a particular value with each other. The names have no other
meaning or usage. Of course the physical_network values being used can
also show up in packstack answer files, various log files, DB tables,
RPC messages, etc., but these are all secondary.

By listing a particular value for physical_network in usage A, two
things occur:

1) That value becomes valid to use as a provider:physical_network value
for usage B. This means admins can create provider flat or vlan networks
using that provider:physical_network attribute value, and might see that
value when running "quantum net-show <name or id>" for existing provider
or tenant networks.

2) If a range of VLAN tags is included on the right-hand-side in usage
A, and tenant_network_type is set to vlan, the specified range of tag
values on that physical_network are added to the pool from which tenant
networks are allocated. Note that multiple ranges can be listed in
network_vlan_ranges, for the same or different physical_network values,
and that overlapping ranges for the same physical_network are OK.


When the openvswitch or linuxbridge L2 agent starts, it processes the
mappings listed in usage C and maintains an internal mapping from the
physical_network name to the corresponding OVS or traditional bridge.
When a port is bound (plugged) on a node, the L2 agent obtains the
port's network's provider attributes. If the network's
provider:network_type value is flat or vlan, the L2 agent uses its
provider:physical_network value (usage B) to lookup the corresponding
bridge via this mapping (usage C), and then sets up connectivity for
that port via that bridge.

That's all there is to it!

I haven't reviewed all of this in detail, but noticed one major issue:

Section 6 has:

 Set the value of the bridge_mappings configuration key. This configuration key must contain a list of physical networks and the VLAN ranges associated with them that are available for allocation to tenant networks.
The format for each entry in the comma separated list is:

PHYSNET:VLAN_START:VLAN_END

Where PHYSNET is replaced with the name of a physical network, VLAN_START is replaced by an identifier indicating the start of the VLAN range, and VLAN_END is replaced by an identifier indicating the end of the VLAN range.
The physical network must have been defined in the network_vlan_ranges configuration variable on the OpenStack Networking server.

# openstack-config --set /etc/quantum/plugin.ini \
   OVS bridge_mappings MAPPINGS

Replace MAPPINGS with the physical network to VLAN range mappings. 


But the format shown is for network_vlan_ranges, not for bridge_mappings. For bridge_mappings, the format is:

PHYSNET:BRIDGE

where PHYSNET is a physical network name listed in network_vlan_ranges on the server, and BRIDGE is the name of the OVS bridge that this agent uses the access the phyiscal network.

Moving back to ASSIGNED and marking FailedQA on the basis of comment # 9.

"Configuring the Open vSwitch Plug-in Agent" - ID: 16753 [rev: 492829]

Moving to QA as an updated build, addressing comment # 9, is now on the stage.