vlan id is reused in multi pod environment

[Shinji YANAGIDA]

In multi-pod environment, vlan id is reused old one.

* The contents of the bug
- Old VLAN ID was assigned to the newly created VM.

* The precondition and expection movement
- Two of physical networks is connected with a subnet.
- vlan id is issued by NWA
- In dynamic segment, When the segmentation_id is 0, it means that the
  vlan id is being allocated.
- Specify each of physical network, and create a VM.
    nova boot --availability-zone AZ1 vm1
    nova boot --availability-zone AZ2 vm2

- When VM is created, create_general_dev is issued for NWA to reserve
  the vlan id. The results are follows.

  vm1 connects to physical network1(AZ1) with vlan id 101.
  vm2 connects to physical network2(AZ2) with vlan id 102.

- Next, delete the vm1, and create vm3 newly.
    nova delete vm1
    nova boot --availability-zone AZ1 vm3

- Issue the command to NWA that vlan id 101, which is assigned in vm1 is
  released and new vlan id is assigned for vm3. The result is
  following.

  vm3 connects to physical network1(AZ1) with vlan id 103.

* Bug

vm3 connects to physical network1 with vlan id 101. Because of this,
the vm3 can't communicate.

* Cause of bug

- Missing of delete and create

  (Normally)
  - When VM has been created (Before correction)
     create_port
       Allocate segment area
       segmentation_id = 0
       create_general_dev -> nwa-agent -> NWA --\
                          <- vlan id <---------/
       segmentation_id = vlan id

  - When VM has been deleted (Before correction)
     delete_port
       delete_general_dev -> nwa-agent -> NWA --\ <-Release vlan id
                          <---------------------/
       Delete segment area

* Bug occurrence
  - Delete VM (Before correction)
     delete_port (vm1)
       delete_general_dev -> nwa-agent -> NWA --\ <-Release vlan id
  - Create VM (Berore correction¡Ë |
     create_port (vm3) |
       Allocate segment area (<- Reuse because the area is already
       allocated) |
       * ovs used vlan id as of this |
       segmentation_id = 0 |
       create_general_dev -> nwa-agent -> NWA --------\
                                                | |
       Delete segment area <--------------------/ |
                                                      |
       Error (Without area)<--- vlan id <-------------/

* After correction
   - Delete VM (After correction¡Ë
     delete_port (vm1)
       Delete segment area
       delete_general_dev -> nwa-agent -> NWA --\ <-Release vlan id
   - Create VM (After correction¡Ë |
     create_port (vm3) |
       Allocate segment area |
       segmentation_id = 0 |
       create_general_dev -> nwa-agent -> NWA --------\
                                                | |
       segmentation_id == 0 <-------------------/ |
       Then nothing is done. |
         (Nothing is also done in cases without area¡Ë|
                                                      |
                        <--- vlan id <----------------/
       segmentation_id = vlan id

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/304590
Committed: https://git.openstack.org/cgit/openstack/networking-nec/commit/?id=9cbfd415f088fdcc30e2b79ec59b730e27517c0b
Submitter: Jenkins
Branch: master

commit 9cbfd415f088fdcc30e2b79ec59b730e27517c0b
Author: Shinji YANAGIDA <email address hidden>
Date: Tue Apr 12 21:42:57 2016 +0900

    Fixed bug that old VLAN ID is used in multi-POD environment

    When a network spreads multiple PODs and port creation is required
    just after port deletion for a same POD, allocation of VLAN ID for
    a network segment (POD) can be racy. As a result, a corresponding
    port creation on NWA fails because VLAN segment is released during
    the operation.

    To fix the bug, this commit makes the following changes:
    * NWA plugin now deletes VLAN ID information from neutron
      DB before calling delete request to NWA.
    * When the delete request completes and if VLAN ID of the requested
      segment is zero (which means another allocation request is ongogin),
      VLAN ID information is not touched.

    Note that this bug does not occurs in a single POD environemnt.

    Change-Id: I2fe86c54063310497ca0091200433e54bb16b198
    Closes-Bug: #1569323