[openstack-dev] [neutron] Scenario test for VPN getting socket error

Paul Michali pc at michali.net
Mon Jun 29 14:21:01 UTC 2015


For review 159746, we are seeing that a traceback is occurring (PS26) that
appears to be caused by two rootwrap commands running at the same time and
trying to use the same socket for communication with the daemon. This
happens in one functional job, and not the other. The difference being that
the failing (dsvm-functional-sswan) has it's own rootwrap function, instead
of  using ip_lib.IPWrapper().

There are two main questions here. One is whether or not we need the custom
rootwrap logic, or if ip_lib methods can be used to mount the desired paths
and run the commands, as needed. There is a mounting of /etc and /var/run.
I'm guessing that the former is to allow customizing of ipsec config files
for the connection being created. I'm not sure why /var/run is mounted (and
if that is interfering with the rootwrap daemon operation).

The other is why this issue is happening with the one job and not the other
(or general use of IPWrapper where there are long running and short running
commands happening at once (and how to resolve this issue). Both jobs do
the same tasks, only with different (external) VPN driver processes.

In the failure case, an execute() is done from ip_lib's get_devices() for a
find operation, and a second execute() is done by send_ip_addr_adv_notif()
for a arping operation (long). In the working case, these two operations
seem to happen simultaneously w/o incident.

Any thoughts on what may be happening, would be appreciated!

Regards,

Paul Michali (pc_m)

Ref:
https://review.openstack.org/#/c/159746/28/neutron_vpnaas/tests/functional/common/test_scenario.py
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150629/1756b359/attachment.html>


More information about the OpenStack-dev mailing list