| 2015-02-03 00:57:22 |
Maru Newby |
description |
When invoking a command via IpNetnsExecFilter, the 'ip' command is automatically qualified depending on where it has been found via exec_dirs (e.g. the 'ip' command is found at '/sbin/ip' and that qualified command is executed). However, a command invoked by ip netns is not similarly qualified such that it being found is entirely dependent on the PATH environment. This is causing problems for neutron functional testing where the target command is in a venv bin directory and a qualified path is required. |
When invoking a command via IpNetnsExecFilter, the 'ip' command is automatically qualified depending on where it has been found via exec_dirs (e.g. the 'ip' command is found at '/sbin/ip' and that qualified command is executed). However, a command invoked by ip netns is not similarly qualified such that it being found is entirely dependent on the PATH environment. This is causing problems for neutron functional testing where the target command is in a venv bin directory and a qualified path is required, e.g.
The following command is executed:
sudo /usr/local/bin/neutron-rootwrap /etc/neutron/rootwrap.conf ip netns exec mynamespace neutron-ns-metadata-proxy
Resulting in:
exec of "neutron-ns-metadata-proxy" failed: No such file or directory
This despite exec_dirs including the path of the neutron-ns-metadata-proxy command.
What should be executed: /sbin/ip netns exec mynamespace /[path to proxy]/neutron-ns-metadata-proxy
What is being executed: /sbin/ip netns exec mynamespace neutron-ns-metadata-proxy |
|
