[Bug 1414218] Re: Remove extraneous trace in linux/dhcp.py

[Chris J Arges]

Hello Billy, or anyone else affected,

Accepted neutron into trusty-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/neutron/1:2014.1.5-0ubuntu5 in a
few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed.  Your feedback will aid us getting this update
out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: neutron (Ubuntu Trusty)
       Status: In Progress => Fix Committed

** Tags added: verification-needed

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to neutron in Ubuntu.
https://bugs.launchpad.net/bugs/1414218

Title:
  Remove extraneous trace in linux/dhcp.py

Status in Ubuntu Cloud Archive:
  Confirmed
Status in neutron:
  Fix Released
Status in neutron juno series:
  Fix Released
Status in neutron package in Ubuntu:
  Fix Released
Status in neutron source package in Trusty:
  Fix Committed

Bug description:
  [Impact]

  The debug tracepoint in Dnsmasq._output_hosts_file is extraneous and
  causes unnecessary performance overhead when creating lots (> 1000)
  ports at one time.

  The trace point is unnecessary since the data is being written to disk
  and the file can be examined in a worst case scenario. The added
  performance overhead is an order of magnitude in difference (~.5
  seconds versus ~.05 seconds at 1500 ports).

  [Test Case]

  1. Deploy OpenStack using neutron for networking
  2. Create 1500 ports
  3. Observe the performance degradation for each port creation.

  [Regression Potential]

  Minimal. This code has been running in stable/juno, stable/kilo, and
  above for awhile.

  [Other Questions]

  This is likely to occur in OpenStack deployments which have large
  networks deployed. The degradation is gradual, but the performance
  becomes unacceptable with large enough networks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1414218/+subscriptions