yahoo-eng-team team mailing list archive

[Ihar Hrachyshka <1645509@xxxxxxxxxxxxxxxxxx>]

We are landing a Mitaka fix. The bug is not present in Newton+. I close
it as fixed.

** Tags added: l3-ipam-dhcp

** Changed in: neutron
       Status: Confirmed => 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/1645509

Title:
  dnsmasq host file entries can return from the grave

Status in neutron:
  Fix Released

Bug description:
  With a Mitaka system, if one creates a Reasonably Large Number (tm) of
  instances (eg 448) via:

  neutron port-create
  neutron floatingip-create <portid>
  nova boot --net portid=<portid>

  and then once they are all created, delete them via:
  delete all the instances via the cCLI (groups of 10 or 14 at a time waiting for CLI completion)
  delete all the ports (groups of 10 or 14 at a time waiting for CLI completion)
  delete the floating IPs (groups of 10 or 14 at a time waiting for CLI completion)

  then as one watches the wc -l for the dnsmasq host file, one can see
  it go down to an expected value of three (the three IPs for the
  network/subnet for DHCP and routing), but then it starts to rebound,
  as entries appear to return from the grave.

  The entries are not specific to a given compute node - they are
  associated with instances across all the compute nodes hosting the
  instances.

  In this specific setup, it did not appear to happen for 224 instances,
  or 112 etc etc.  It seems to have happened at least twice out of three
  attempts at 448 instances.

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