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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
