Open Stack

The latter. If you look at Jenkins results for 168115, it shows that there
is an invalid config file at /etc/neutron/rootwrap.conf. However, it should
be accessing
/opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/etc/neutron/rootwrap.conf.

The deploy_rootwrap.sh call in tox.ini should place the files in the .tox
area (it does locally), and the OS_ROOTWRAP_CMD (and
OS_ROOTWRAP_DAEMON_CMD) are set to these areas as well. It just seems that
the rootwrap daemon is not using the right file.

In the latest run, I dumped out environment variables, which show this:

2015-04-24 15:19:15.499
<http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_2015-04-24_15_19_15_499>
| 2015-04-24 15:19:15.466 | OS_ROOTWRAP_DAEMON_CMD=sudo
/opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/bin/neutron-rootwrap-daemon
/opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/etc/neutron/rootwrap.conf2015-04-24
15:19:15.499 <http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_2015-04-24_15_19_15_499>
| 2015-04-24 15:19:15.467 | OS_SUDO_TESTING=12015-04-24 15:19:15.499
<http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_2015-04-24_15_19_15_499>
| 2015-04-24 15:19:15.469 | OS_ROOTWRAP_CMD=sudo
/opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/bin/neutron-rootwrap
/opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/etc/neutron/rootwrap.conf


I have added a test case in the module that is failing that shows the value
of cfg.CONF.AGENT.root_helper_daemon. It shows:

sudo
/opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/bin/neutron-rootwrap-daemon
/opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/etc/neutron/rootwrap.conf

Is that correct?

When the test cases run, there is this error:

2015-04-24 15:19:18.536
<http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_2015-04-24_15_19_18_536>
| 2015-04-24 15:19:18.486 |     2015-04-24 15:19:17.986 31628 INFO
oslo_rootwrap.client [-] Spawned new rootwrap daemon process with
pid=316672015-04-24 15:19:18.536
<http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_2015-04-24_15_19_18_536>
| 2015-04-24 15:19:18.487 |     2015-04-24 15:19:18.470 31628 ERROR
neutron.agent.linux.utils [-] 2015-04-24 15:19:18.536
<http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_2015-04-24_15_19_18_536>
| 2015-04-24 15:19:18.489 |     Command: ['neutron-vpn-netns-wrapper',
'--mount_paths=/etc:/var/lib/neutron/vpnaas/func-8f1b728c-6eca-4042-9b6b-6ef66ab9352a/etc,/var/run:/var/lib/neutron/vpnaas/func-8f1b728c-6eca-4042-9b6b-6ef66ab9352a/var/run',
'--cmd=nofiltercommand']2015-04-24 15:19:18.537
<http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_2015-04-24_15_19_18_537>
| 2015-04-24 15:19:18.490 |     Exit code: 222015-04-24 15:19:18.537
<http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_2015-04-24_15_19_18_537>
| 2015-04-24 15:19:18.492 |     Stdin: 2015-04-24 15:19:18.537
<http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_2015-04-24_15_19_18_537>
| 2015-04-24 15:19:18.493 |     Stdout: 2015-04-24 15:19:18.537
<http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_2015-04-24_15_19_18_537>
| 2015-04-24 15:19:18.495 |     Stderr: 2015-04-24 15:19:18.456 31727
ERROR neutron_vpnaas.services.vpn.common.netns_wrapper [-] Incorrect
configuration file: /etc/neutron/rootwrap.conf

Now, there is a vpnaas.filters file that I copy into the rootwrap.d
area, using this command in the tox.ini:

cp {toxinidir}/etc/neutron/rootwrap.d/vpnaas.filters
{envdir}/etc/neutron/rootwrap.d/

The file has the neutorn-vpn-netns-wrapper entry in it. Maybe the copy
is failing?

Regards,

PCM


On Sun, Apr 26, 2015 at 9:39 PM Angus Lees <gus at inodes.org> wrote:

> 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
>>
> __________________________________________________________________________
> 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/6f86229a/attachment.html>