yahoo-eng-team team mailing list archive

[Ihar Hrachyshka <1687065@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Example: http://logs.openstack.org/27/451527/5/check/gate-neutron-dsvm-
functional-ubuntu-xenial/da67f5f/logs/dsvm-functional-
logs/neutron.tests.functional.agent.linux.test_linuxbridge_arp_protect.LinuxBridgeARPSpoofTestCase.test_arp_protection_update.txt.gz

This test has nothing to do with ovs, but still, it's trashed with
POLLIN messages. Probably because some previous test case in the worker
initialized ovslib and got a logging thread spinned up.

Ideally, we would not have the thread running in non-ovs scope, meaning
we would need some way to kill/disable it when not needed. Maybe a
fixture in ovsdbapp for that matter (or ovs lib itself) that would
restore the state to pre-init could help. Then we could use the fixture
in our base test classes.

** Affects: neutron
     Importance: Low
         Status: Confirmed

** Affects: ovsdbapp
     Importance: Undecided
         Status: Confirmed


** Tags: functional-tests usability

** Changed in: ovsdbapp
       Status: New => Confirmed

** Also affects: neutron
   Importance: Undecided
       Status: New

** Changed in: neutron
       Status: New => Confirmed

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

** Tags added: functional-tests usability

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1687065

Title:
  functional tests are filled with POLLIN messages from ovs even when
  it's not using ovs itself

Status in neutron:
  Confirmed
Status in ovsdbapp:
  Confirmed

Bug description:
  Example: http://logs.openstack.org/27/451527/5/check/gate-neutron-
  dsvm-functional-ubuntu-xenial/da67f5f/logs/dsvm-functional-
  logs/neutron.tests.functional.agent.linux.test_linuxbridge_arp_protect.LinuxBridgeARPSpoofTestCase.test_arp_protection_update.txt.gz

  This test has nothing to do with ovs, but still, it's trashed with
  POLLIN messages. Probably because some previous test case in the
  worker initialized ovslib and got a logging thread spinned up.

  Ideally, we would not have the thread running in non-ovs scope,
  meaning we would need some way to kill/disable it when not needed.
  Maybe a fixture in ovsdbapp for that matter (or ovs lib itself) that
  would restore the state to pre-init could help. Then we could use the
  fixture in our base test classes.

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