yahoo-eng-team team mailing list archive

[OpenStack Infra <1718788@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/505324
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=27fcf86bcbf4a66f52385f0efea956f13c38d7b2
Submitter: Jenkins
Branch:    master

commit 27fcf86bcbf4a66f52385f0efea956f13c38d7b2
Author: Swaminathan Vasudevan <SVasudevan@xxxxxxxx>
Date:   Tue Sep 19 06:54:14 2017 -0700

    DVR: Fix unbound fip port migration to bound port
    
    With the current change in allowing the unbound fip
    to be associated with the snat node, we are seeing
    that all floating IPs that are associated with an
    unbound port are created at the snat node.
    This is also applicable for floating IPs that are
    created just before associating the port to a VM.
    We have seen such scenarios in the test cases.
    
    This is the right behavior as per design. But when
    the port is bound to a host, the floating IP should
    be migrated to the respective host.
    
    This patch fixes the issue by sending notification to
    the respective node, when the port is bound and also
    clear the fip from the snat node.
    
    Closes-Bug: #1718788
    Change-Id: I6b1f3ffc3c3336035632f6a82d3a87b3be57b403


** 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/1718788

Title:
  DVR: Migrate centralized unbound floatingip to the respective host
  when  the port is bound

Status in neutron:
  Fix Released

Bug description:
  When unbound ports are associated with floatingIP in DVR, it implements the floatingIP in the dvr_snat node under the snat_namespace.
  When the private ports are bound to a specific host, the floatingIPs are not moved or migrated to their respective hosts.

  This can be reproduced by 
  1. Create a network
  2. Create a subnet
  3. Create a router and associate the subnet to the router
  4. Assign a gateway to the router.
  5. Then create a port on the given network with a specific IP.
  6. Now create a FloatingIP on the external network.
  7. Associate the FloatingIP to the created port.
  8. At this point the port is not bound and so the floatingIP gets implemented in the Snat_namespace in the dvr_snat node.
  9. Then within a few seconds, we create a VM with the given port-id instead of network-id.
  10. Now when the VM is built then the port gets bound.
  11. Now the floatingIP is not seen on the host where the VM resides.

  Theoretically the FloatingIP should be migrated to the host where it
  is currently bound.

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