Open Stack

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 <ihrachys at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150427/05c57958/attachment.html>