I don't know whether i got your point. But try to modify 
/neutron/tests/unit/services/vpn/test_vpnaas_driver_plugin.py like the 
following, the error would be fixed: 
--- a/neutron/tests/unit/services/vpn/test_vpnaas_driver_plugin.py 
+++ b/neutron/tests/unit/services/vpn/test_vpnaas_driver_plugin.py 


@@ -17,6 +17,7 @@ 
import contextlib 

import mock 
+from oslo.config import cfg 

from neutron.common import constants 
from neutron import context 
@@ -44,6 +45,11 @@ class TestVPNDriverPlugin(test_db_vpnaas.TestVpnaas, 
self.driver = mock.Mock() 
self.driver.service_type = ipsec_driver.IPSEC 
driver_cls.return_value = self.driver 
+ vpnaas_provider = (p_constants.VPN + 
+ ':vpnaas:neutron.services.vpn.' 
+ 'service_drivers.ipsec.IPsecVPNDriver:default' ) 
+ cfg.CONF.set_override('service_provider', 
+ [vpnaas_provider], 'service_providers') 
super(TestVPNDriverPlugin, self).setUp( 
vpnaas_plugin=VPN_DRIVER_CLASS) 


----- Original Message -----

From: "Paul Michali" <p...@cisco.com> 
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org> 
Sent: Tuesday, March 4, 2014 1:28:48 PM 
Subject: [openstack-dev] Neutron: Need help with tox failure in VPN code 

Hi, 

I'm stuck and can use some guidance here…please! 

I have a change set out for review that used the VPN Service Type Framework ( 
https://review.openstack.org/74144 ). Everything worked fine, passed Jenkins, 
etc. 

Found out that the STF won't make it to I-3, so I removed the dependency from 
my change set and tried to modify the plugin.py file to use some STF logic 
(like LBaaS uses) to load the desired service driver that is specified as the 
default. Adjusted the code to no longer use provider info. 

Well, in doing so, tox fails, and unfortunately there little info on the 
failure. This can be seen by running a subset of the tests, where 2 fail: 

tox -e py27 -v -- neutron.tests.unit.services.vpn 

only the name of a failing test case for one, and a mention of return code 10 
on another and no other info on the failure reason. I didn't see this on a full 
tox run in my repo, but Jenkins failed and Akihiro noticed it too, in running 
the above subset of the suite (thanks!). 


I've narrow it down a bit, but have no idea why it fails… 

One, it seems to be some interaction between test_vpnaas_driver_plugin.py and 
the two service driver tests (cisco_ipsec.py and ipsec.py). I can remove either 
one of the service driver tests cases, and it will still fail with the other 
one (so even the reference code fails). 

Two, if I change plugin.py to set self.driver to the reference device driver 
(as is done in the latest patch set) it works fine with all test cases. 

Three, it seems to be a test only issue, because I can run devstack with the 
login I have in plugin.py, currently commented out in __init__(), and 
successfully load either the reference or cisco service driver, by changing 
neutron.conf. 

It seems like I'm doing something wrong in the loading of the service driver, 
or using this implementation, is somehow interacting with the tests. 

If anyone has ideas on what is wrong, or a better way to load the service 
driver, please let me know. I was thinking I could read and parse neutron.conf 
manually and then load the service driver, but there must be a better way! 

Thanks! 

PCM (Paul Michali) 

MAIL p...@cisco.com 
IRC pcm_ ( irc.freenode.net ) 
TW @pmichali 
GPG key 4525ECC253E31A83 
Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 


_______________________________________________ 
OpenStack-dev mailing list 
OpenStack-dev@lists.openstack.org 
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=J3ghWIVLPZdVsutjofb71dKYtoj4XxhrER%2FD8VzKRX0%3D%0A&s=09cf53ed99065938661b61453a717d77ba3b1ec069c48e356b358d472d3b526a
 

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to