Bug 961133 - OVS L2 Agent looks for bridge changes via inefficient polling
OVS L2 Agent looks for bridge changes via inefficient polling
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron (Show other bugs)
Unspecified Unspecified
medium Severity medium
: Upstream M3
: 5.0 (RHEL 7)
Assigned To: Maru Newby
Ofer Blaut
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2013-05-08 17:28 EDT by Maru Newby
Modified: 2016-04-26 18:35 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-11-17 02:17:09 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1177973 None None None Never
OpenStack gerrit 45676 None None None Never
OpenStack gerrit 45677 None None None Never
OpenStack gerrit 45678 None None None Never

  None (edit)
Description Maru Newby 2013-05-08 17:28:17 EDT
See upstream bug: https://bugs.launchpad.net/quantum/+bug/1177973
Comment 3 Ofer Blaut 2013-10-17 02:44:45 EDT
Hi Maru
We need info how to test it on non dev stack setup , is looking on CPU is enough ? 

Comment 4 Maru Newby 2013-10-21 13:09:32 EDT
Ofer: Validation could include detecting the invocation rate for ovs-vsctl (the command which polling minimization affects) , since the cpu load would vary by the performance of a given system.  I would also suggest killing the monitor process and ensuring that the agent falls back to polling (if no respawn interval is provided) or respawns the monitor process (if respawn interval is provided).
Comment 5 Maru Newby 2013-11-14 09:16:54 EST
The upstream didn't merge in time for Havana, and therefore doesn't have to be considered for 4.0.

Note You need to log in before you can comment on or make changes to this bug.