[openstack-dev] [neutron] Need guidance - functional tests and rootwrap

Ihar Hrachyshka ihrachys at redhat.com
Fri Apr 24 14:44:35 UTC 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/24/2015 04:02 PM, Ihar Hrachyshka wrote:
> On 04/24/2015 03:48 PM, Paul Michali wrote:
>> Hi, I'm floundering a bit, and could use some guidance on
>> this...
> 
>> For the neutron-vpnaas repo, I am trying to modify the
>> functional jobs (dsvm-functional and dsvm-functional-sswan) to
>> act in a similar manner to neutron, where devstack is configured,
>> but no stacking is performed.
> 
>> I'm trying to do the same thing and have the jobs doing the 
>> configuration only. Side note: there are two jobs, because there 
>> are currently two reference implementations of VPN drivers, each
>> of which require a different IPSec package installed.
> 
>> As part of this setup, in tox.ini, the neutron
>> deploy_rootwrap.sh script is called which places the rootwrap
>> filters and config file in the repo's
>> .tox/dsvm-functional/etc/neutron/ area (or 
>> ./tox/dsvm-functional-sswan/etc/neutron/).
> 
>> Now, the issue I see is that tests trying to run "ip" commands, 
>> are failing saying that the config file is invalid:
> 
>> ERROR neutron_vpnaas.services.vpn.common.netns_wrapper [-] 
>> Incorrect configuration file: /etc/neutron/rootwrap.conf
> 
>> As you can see, this is trying to access the rootwrap.conf in 
>> /etc/neutron and not the one in 
>> /opt/stack/new/neutron-vpnaas/.tox/dsvm-functioanl-sswan/etc/neutron/
.
>
>>  For Neutron, how is the dsvm-functional job directing the 
>> rootwrap daemon to use the files in the repo's .tox area?
> 
> It may be the case that oslo_config.cfg.find_config_files is
> involved, doing its dirty config file autodiscovery job. May I ask
> you to try out [1] that is designed to avoid it, and report back
> with the result?
> 
> [1]:
> https://review.openstack.org/#/c/172354/1/neutron/tests/base.py
> 

Nah, that won't help for rootwrap. It does not even rely on
oslo.config, and the config file is passed with CLI args. I recommend
checking what's cfg.CONF.AGENT.root_helper_daemon value inside your
failing test cases to see whether tox properly passed
OS_ROOTWRAP_DAEMON_CMD, with {envdir} properly substituted.

Ihar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVOlbTAAoJEC5aWaUY1u57zkgH+wa5yvVYqglN+B7qpkIfR5QB
5X+6fh9O2KNV8qkDkSKwfRgqs8UouNGOO39zYcgG/QOlqfRKv9ROGkLyNzRihaRg
ynmDSiXVSiW/wnW+R8ymBSFiU30O88jtlBxlwYYUlz1pdbdQxpVUWPspvYrYU95O
zdBkifNEvDpYhb/DySq6dlOJB+VQ2IlnCsBhkZeiKQz/T2fnYDoTNZ05beLZez2s
kntPkYXG11dYRDYQxF76A3fFSboiy2TkX7wl8wK29WQI350gk3Fc/ob0QlMYR0Kf
IcvEHh+g7cvkZkcX3vn3dDTnI9WUorDUjvnvfw8PGvJaB/edniUBjSC6HHmhBv8=
=Pg+J
-----END PGP SIGNATURE-----



More information about the OpenStack-dev mailing list