yahoo-eng-team team mailing list archive

[Paul Michali <1360435@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

During review of some UT code for VPNaaS
(https://review.openstack.org/110432) it was found that the tests were
failing in Jenkins, with a cryptic StringException and no traceback.

The root cause of that was found to be that two test classes were
instantiating a VPN plugin, which in turn calls the Service Type
Manager's load_driver() standalone method. This method will create/get
an instance of the service type manager. As part of that, it will call
load_conf, which creates a ProviderConfiguration object and reads in a
configuration multistring into a dictionary.

When multiple tests run in parallel, it appears that the dictionary can
be munged by concurrent access during construction.

For 110432, the workaround was to create a unique (non-singleton)
instance of the service type manager.  However, we shuld probably lock
the access to this load_conf() method (change the singleton design, or
don't use a class).

** Affects: neutron
     Importance: Undecided
         Status: New

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

Title:
  Service Type Manager singleton needs protection

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  During review of some UT code for VPNaaS
  (https://review.openstack.org/110432) it was found that the tests were
  failing in Jenkins, with a cryptic StringException and no traceback.

  The root cause of that was found to be that two test classes were
  instantiating a VPN plugin, which in turn calls the Service Type
  Manager's load_driver() standalone method. This method will create/get
  an instance of the service type manager. As part of that, it will call
  load_conf, which creates a ProviderConfiguration object and reads in a
  configuration multistring into a dictionary.

  When multiple tests run in parallel, it appears that the dictionary
  can be munged by concurrent access during construction.

  For 110432, the workaround was to create a unique (non-singleton)
  instance of the service type manager.  However, we shuld probably lock
  the access to this load_conf() method (change the singleton design, or
  don't use a class).

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