has the active path of the pipe lookup_plugin changed

Archives Ansible Developer
1

Hey all,

I might have missed a changelog but I can’t seem to find this change documented:

When setting a variable to the value “{{ lookup(‘pipe’, ‘pwd’) }}” in the root of a playbook, and then using that variable inside a role, the working directory for the command has changed between ansible versions 1.5.5 and 1.6.0

In 1.5.5: it’s the location of the playbook
In 1.6.0: it’s the “tasks” folder of the role, or - if the role contains a “files” folder, it’s that.

Here’s a test repo:
https://github.com/ramondelafuente/ansible-lookup-plugin-tests

Condensed results for the command “ansible --version && ansible-playbook -i testing/hosts testing/playbook.yml”:

ansible 1.5.5
TASK: [test_role_with_files | task_in_role_wit_files_variable] ****************
“local_file_name”: “/Users/fzz/Projects/future500/vps-provisioning/testing”
TASK: [test_role_with_files | task_in_role_with_files_lookup_plugin] **********
“msg”: “/Users/fzz/Projects/future500/vps-provisioning/testing/test_role_with_files/files”
TASK: [test_role_without_files | task_in_role_without_files_variable] *********
“local_file_name”: “/Users/fzz/Projects/future500/vps-provisioning/testing”
TASK: [test_role_without_files | task_in_role_without_files_lookup_plugin] ****
“msg”: “/Users/fzz/Projects/future500/vps-provisioning/testing/test_role_without_files/tasks”
TASK: [task_in_playbook_with_variable] ****************************************
“local_file_name”: “/Users/fzz/Projects/future500/vps-provisioning/testing”
TASK: [task_in_playbook_with_lookup_plugin] ***********************************
“msg”: “/Users/fzz/Projects/future500/vps-provisioning/testing”

ansible 1.6.1
TASK: [test_role_with_files | task_in_role_wit_files_variable] ****************
“local_file_name”: “/Users/fzz/Projects/future500/vps-provisioning/testing/test_role_with_files/files”
TASK: [test_role_with_files | task_in_role_with_files_lookup_plugin] **********
“msg”: “/Users/fzz/Projects/future500/vps-provisioning/testing/test_role_with_files/files”
TASK: [test_role_without_files | task_in_role_without_files_variable] *********
“local_file_name”: “/Users/fzz/Projects/future500/vps-provisioning/testing/test_role_without_files/tasks”
TASK: [test_role_without_files | task_in_role_without_files_lookup_plugin] ****
“msg”: “/Users/fzz/Projects/future500/vps-provisioning/testing/test_role_without_files/tasks”
TASK: [task_in_playbook_with_variable] ****************************************
“local_file_name”: “/Users/fzz/Projects/future500/vps-provisioning/testing”
TASK: [task_in_playbook_with_lookup_plugin] ***********************************
“msg”: “/Users/fzz/Projects/future500/vps-provisioning/testing”

The question is: Was this intended?
(sparked by this stackoverflow question http://stackoverflow.com/a/24252727/601704)

kind regards,

Ramon de la Fuente

2

The pipes lookup itself does not appear to have changed, the call to Popen still uses cwd=self.basedir, which has not changed in 2 years as far as I can tell from git logs.

However, based on your output above it does appear that the basedir value has changed somewhat. I’m not sure if that’s a bug, because for a role it would make more sense for it to be looking in the current directory of the tasks/main.yml than the playbook directory itself. Feel free to open a github issue in regards to this and we can dig into it.

3

Yeah , like I said - I could not find the change in the change log or in code (did not look beyond the plugin either).

I find the new behaviour slightly counter-intuitive because I cannot use the pipe lookup plugin to fill a path variable in a pre-task; it’s value will be different when run in the actual role. On the other hand, the plugins each have their purpose and like you said - it might make more sense for them to work within context.

Long story short: I’m not sure it’s a bug either - I was just wondering if this was intentional or a side-effect. I’ve put my findings out there, for me there’s no need to open an issue.

kind regards,

4

Definitely a side effect. Go ahead and open an issue and we can at least bisect it to find out the responsible commit.

5

Done: https://github.com/ansible/ansible/issues/7834

6

Using the roles basedir seems correct to me and we’ve closed this one out.