yahoo-eng-team team mailing list archive

[OpenStack Infra <1554825@xxxxxxxxxxxxxxxxxx>]

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

commit aa00310eef0d2507c4da76eb5dd5130df043b0a5
Author: Shih-Hao Li <shihli@xxxxxxxxxx>
Date:   Fri Mar 11 15:13:34 2016 -0800

    Update network object in DHCP agent with router interface changes
    
    In Dnsmasq, the function get_isolated_subnets() returns a list of
    subnets in a network if the subnet is not connected to a router.
    
    The implementation of this function checks all the router interface
    ports in a cached network object passed from DHCP agent. But the
    cached network object is not updated when a subnet is attached to
    or detached from a router.
    
    This patch fixes that by adding callback functions in DHCP RPC client
    to notify DHCP agent when changes happen on router interfaces.
    
    Closes-Bug: #1554825
    Change-Id: Ifaab163f49e0d1c5cb3eba6efa96214104647e4e


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

Title:
  Cached network object in DHCP agent not updated with router interface
  changes

Status in neutron:
  Fix Released

Bug description:
  In Dnsmasq, the function get_isolated_subnets() returns a list of
  subnets in a network if the subnet is not connected to a router.

  The implementation of this function checks all the router interface
  ports in a cached network object passed from DHCP agent. But the
  cached network object is not updated when a subnet is attached to or
  detached from a router.

  This could cause problem when a new VM is booted on a subnet just
  attached to a router. The VM will get the metadata route to the DHCP
  port instead of to the route port from Dnsmasq.

  Based on current DHCP agent implementation, if DHCP agent is
  restarted, it will try to restart all metadata proxies. But it will
  skip the metadata proxy for the networks with any subnet attached to a
  router. Instead, DHCP agent will start a metadata-proxy for the
  router. If old metadata proxy processes for the networks are still
  running, then the metadata route to the DHCP port should still work.
  But consider the case when a openstack network node is restarted, then
  all old processes are gone. Thus DHCP agent will not start those
  metadata proxies for networks with attached router. This means any VM
  that has routing table containing a metadata route to the DHCP port
  will fail to reach metadata service because the corresponding metadata
  proxy that handle 169.254.169.254:80 is not running.

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