← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1352932] [NEW] NVP plugin extension lswitch created with wrong transport zone binding

 

Public bug reported:

Nicira NVP plugin create extension lswitches when port number on a
bridged (flat) network reaches upper limit (configured by
max_lp_per_bridged_ls in nvp.ini).

However, in Havana version, when extension lswitches are created for
"flat" networks, it use wrong transport zone binding.

Expected: use same transport zone binding as specified by the network.

Result: use default transport zone binding configured by default_tz_uuid
and default_transport_type in nvp.ini.

This bug is introduced in Havana version.

Root cause:
in Havana, tz_uuid was generated in a new function _convert_to_nvp_transport_zones(), and it checks if mpnet.SEGMENTS is not set for the network, the default tz_uuid and transport type are used:
        if (network and not attr.is_attr_set(
            network.get(mpnet.SEGMENTS))):
            return [{"zone_uuid": cluster.default_tz_uuid,
                     "transport_type": cfg.CONF.NVP.default_transport_type}]

For a bridged network without VLAN, this mpnet.SEGMENTS is not set. So
the function returns with the default binding rather than use the tz
binding of the specified network.

** Affects: neutron
     Importance: Undecided
         Status: New


** Tags: nicira

** Tags added: nicira

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

Title:
  NVP plugin extension lswitch created with wrong transport zone binding

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Nicira NVP plugin create extension lswitches when port number on a
  bridged (flat) network reaches upper limit (configured by
  max_lp_per_bridged_ls in nvp.ini).

  However, in Havana version, when extension lswitches are created for
  "flat" networks, it use wrong transport zone binding.

  Expected: use same transport zone binding as specified by the network.

  Result: use default transport zone binding configured by
  default_tz_uuid and default_transport_type in nvp.ini.

  This bug is introduced in Havana version.

  Root cause:
  in Havana, tz_uuid was generated in a new function _convert_to_nvp_transport_zones(), and it checks if mpnet.SEGMENTS is not set for the network, the default tz_uuid and transport type are used:
          if (network and not attr.is_attr_set(
              network.get(mpnet.SEGMENTS))):
              return [{"zone_uuid": cluster.default_tz_uuid,
                       "transport_type": cfg.CONF.NVP.default_transport_type}]

  For a bridged network without VLAN, this mpnet.SEGMENTS is not set. So
  the function returns with the default binding rather than use the tz
  binding of the specified network.

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


Follow ups

References