← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1602294] Re: check_vlan_transparency on mech drivers not called

 

Reviewed:  https://review.openstack.org/341003
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=09736ed06436330d81786bc8ced8a681b14f17a7
Submitter: Jenkins
Branch:    master

commit 09736ed06436330d81786bc8ced8a681b14f17a7
Author: Erik Colnick <erik.colnick@xxxxxxx>
Date:   Tue Jul 12 02:47:37 2016 -0600

    Fix for check_vlan_transparency on mech drivers not called
    
    The check_vlan_transparency method on mech drivers is never
    called by the neutron/plugins/ml2/managers.py MechanismManager
    _check_vlan_transparency method since that method is invoked
    before 'vlan_transparent' has been set in the context.
    This fix moves the block in neutron/plugins/ml2/plugin.py
    ML2Plugin._create_network_db to before the call to
    'self.mechanism_manager.create_network_precommit(mech_context)'
    so that vlan_transparent exists in the context when the
    MechanismManager checks.
    
    Change-Id: I8e47ccdebf0cb954109195e8a8ba39a1c82f97a8
    Closes-Bug: #1602294


** Changed in: neutron
       Status: In Progress => 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/1602294

Title:
  check_vlan_transparency on mech drivers not called

Status in neutron:
  Fix Released

Bug description:
  In a devstack installation with 'vlan_transparent = True' in neutron.conf and 'mechanism_drivers = openvswitch,l2population' set in the [ml2] section of ml2_conf.ini, I was able to successfully execute a net-create command with '--vlan-transparent True':
  $ neutron net-create --vlan-transparent True test
  Created a new network:
  +-------------------------+--------------------------------------+
  | Field                   | Value                                |
  +-------------------------+--------------------------------------+
  | admin_state_up          | True                                 |
  | availability_zone_hints |                                      |
  | availability_zones      |                                      |
  | created_at              | 2016-07-12T14:05:02                  |
  | description             |                                      |
  | id                      | 12cba5b4-8e49-421f-a36a-b390fc3d93b3 |
  | ipv4_address_scope      |                                      |
  | ipv6_address_scope      |                                      |
  | mtu                     | 1450                                 |
  | name                    | test                                 |
  | port_security_enabled   | True                                 |
  | router:external         | False                                |
  | shared                  | False                                |
  | status                  | ACTIVE                               |
  | subnets                 |                                      |
  | tags                    |                                      |
  | tenant_id               | 48c3d57170b745cbaf4ee0186b64405a     |
  | updated_at              | 2016-07-12T14:05:02                  |
  | vlan_transparent        | True                                 |
  +-------------------------+--------------------------------------+

  I would have expected this to fail with a message like:

  $ neutron net-create --vlan-transparent True test
  Backend does not support VLAN Transparency.

  since the 'check_vlan_transparency' method in mech_openvswitch.py
  returns 'False'.  Looking into the neutron/plugins/ml2/managers.py
  code, I found that in the
  MechanismManager.create_network_precommit(self, context) method,
  _check_vlan_transparency(context) is called before 'vlan_transparent'
  has been set in the context, so that the call to the mech driver
  check_vlan_transparency(context) method is never called.

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


References