The tox.ini entry for dsvm-fullstack sets OS_ROOTWRAP_CMD=sudo {envbindir}/neutron-rootwrap {envdir}/etc/neutron/rootwrap.conf (and something similar for rootwrap-daemon).
Is this the answer you were looking for, or are you saying OS_ROOTWRAP_CMD doesn't appear to be honoured in your case? - Gus On Sat, 25 Apr 2015 at 00:45 Ihar Hrachyshka <ihrac...@redhat.com> wrote: > -----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----- > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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