yahoo-eng-team team mailing list archive

[OpenStack Infra <1824802@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/658307
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=5c433a027daab2419d974820589205253871885e
Submitter: Zuul
Branch:    master

commit 5c433a027daab2419d974820589205253871885e
Author: Slawek Kaplonski <skaplons@xxxxxxxxxx>
Date:   Fri May 10 10:47:00 2019 +0200

    [DHCP] Don't resync network if same port is alredy in cache
    
    Sometimes when port is created on dhcp agent's side, it may happend
    that same port is already in network cache.
    Before this patch if port with same IP address was already in cache,
    resync was rescheduled because of duplicate IPs found in cache.
    
    Now resync will be scheduled only if duplicate IP address belongs to
    port with different MAC address or different id.
    
    Change-Id: I23afbc10725f5dc78e3c63e6e505ef89ba8dc4a5
    Closes-Bug: #1824802


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

Title:
  dhcp agent dnsmasq process mgmt race condition between launch and
  operations

Status in neutron:
  Fix Released

Bug description:
  There may be a race condition involving dnsmasq startup and port
  operations. What appears to happen is that dnsmasq is started but the
  pid file isn't available when a port change occurs. The dhcp agent
  then attempts to start a new dnsmasq instance even though the previous
  one is the process of being loaded. Tricky to reproduce manually but
  does seem to occur in tempest tests.

  Note: this is currently being observed in TripleO ML2/OVS tests. As
  dnsmasq is run in a container with a well-defined-name so when the
  second container launch fails to because of a naming collision.

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