← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1300355] [NEW] Ip allocations can leak with dnsmasq restart

 

Public bug reported:

There is a small error in the logic of how we handle releasing fixed
ips. When dnsmasq is restarted, it calls nova-dhcpbridge to list the
existing leases that nova knows about. Currently we only return leases
for ips that are allocated. Since we deallocate addresses before we
reload dnsmasq, this can cause dnsmasq to lose knowledge of the ip
addresses. The result is that the release dhcp packet does not end up
triggering a DEL message in nova-dhcpbridge, and the leased flag remains
set.

Note that this will only very rarely cause an issue in the current code
base, since we generally HUP dnsmasq instead of reloading it. Some
changes to dnsmasq do require a full restart (to handle different
domains, for example), so this has the potential to cause surprising
bugs in the future. The ip will eventually recovered by a cleanup task,
but the logic in this path should be fixed.

** Affects: nova
     Importance: Low
     Assignee: Vish Ishaya (vishvananda)
         Status: In Progress

** Changed in: nova
   Importance: Undecided => Low

** Changed in: nova
       Status: New => In Progress

** Changed in: nova
     Assignee: (unassigned) => Vish Ishaya (vishvananda)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1300355

Title:
  Ip allocations can leak with dnsmasq restart

Status in OpenStack Compute (Nova):
  In Progress

Bug description:
  There is a small error in the logic of how we handle releasing fixed
  ips. When dnsmasq is restarted, it calls nova-dhcpbridge to list the
  existing leases that nova knows about. Currently we only return leases
  for ips that are allocated. Since we deallocate addresses before we
  reload dnsmasq, this can cause dnsmasq to lose knowledge of the ip
  addresses. The result is that the release dhcp packet does not end up
  triggering a DEL message in nova-dhcpbridge, and the leased flag
  remains set.

  Note that this will only very rarely cause an issue in the current
  code base, since we generally HUP dnsmasq instead of reloading it.
  Some changes to dnsmasq do require a full restart (to handle different
  domains, for example), so this has the potential to cause surprising
  bugs in the future. The ip will eventually recovered by a cleanup
  task, but the logic in this path should be fixed.

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


Follow ups

References