yahoo-eng-team team mailing list archive

[rick jones <1645509@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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.

** Affects: neutron
     Importance: Undecided
     Assignee: Kevin Benton (kevinbenton)
         Status: Confirmed

-- 
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:
  Confirmed

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