yahoo-eng-team team mailing list archive

[Thierry Carrez <thierry.carrez+lp@xxxxxxxxx>]

** Changed in: neutron
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1491668

Title:
  deprecate external_network_bridge option in L3 agent

Status in neutron:
  Fix Released

Bug description:
  The external_network_bridge option in the L3 agent allows the L3 agent
  to plug directly into a bridge and skip all of the management by the
  L2 agent. This creates two ways to accomplish the same wiring, but it
  results in differences that cause confusion a issues for debugging.

  When the external_network_bridge option is used, all of the provider
  properties (e.g. VLAN tags, VXLAN VNIs) of the external network are
  ignored. So we end up with scenarios where users will create an
  external network with a VLAN tag, attach a router to it, and then
  complain when it's not sending the correct tagged traffic. It also
  means that features added to the L2 agent will not apply to router
  ports (e.g. enhanced debugging, QoS, port mirroring, etc).

  The appropriate way to do this is to define a physnet for the external
  network (e.g. 'external') and then create a bridge_mapping entry for
  it on the L2 agent that maps it to the external bridge (e.g. 'external
  :br-ex'). Then when the external Neutron network is created, it should
  be created with the 'flat' provider type and the 'external' provider
  physnet.

  We should deprecate external_network_bridge in L and remove it in M to
  migrate people to the more consistent approach with bridge_mappings.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1491668/+subscriptions