Add ansible.cfg variables that expand to ansible.cfg path and playbook path

[ssbarnea]

Proposal: path-variables for ansible.cfg

Author: Sorin Sbarnea <@ssbarnea> IRC: ssbarnea

Date: 2017/09/19

• Status: New
• Proposal type: core
• Targeted Release: 2.4
• Associated PR: TBD
• Estimated time to implement: 3 days

Motivation

Currently it is impossible to run playbooks from various CWD as they will fail to load the hosts file. ansible.cfg supports only paths relative to CWD.

We want to avoid changing default behaviour as this would alienate users but we can fix the problem by enabling users to use an expanding variable that gives the path of ansible.cfg or even the playbook itself.

Problems

• unable to call playbooks from different directories
• unable to keep playbooks in different directories
• unable to safely move playbooks between directories

Solution proposal

One similar example is tox tool which has {toxinidir} variable which can be used inside the tox.ini config file to create paths relative to it. This allows people to safely run tox from anywhere.

I propose adding {ansiblecfgdir} and {playbookdir} variables with the remarks the the later one should fallback to ansiblecfgdir value for the few cases where ansible is called without any playbook, like direct module call.

With these two variable people should be able to configure their ansible.cfg in such way that ansible does not fail to find the paths.

The expansion should work for at least these configuration items

• [defaults] inventory
• [defaults] library
• [defaults] callback_plugins
• [defaults] action_plugins
• [defaults] roles

We should also ask ourselves if this expansion cannot be enabled for ALL values inside the ansible.cfg file.

Reference https://github.com/ansible/ansible/issues/5185

[dagwieers]

Good point, the other day I had to explain $CUSTOMER the inconsistent way Ansible works because of this (e.g. ansible vs ansible-playbook). Having to make symlinks in the playbookdir (or CWD) just in order to make ends meet should be avoided. Explicit is better than implicit.

[bcoca]

Before 2.4 relative paths in ansible.cfg, depended on the setting, which was confusing and undocumented

In 2.4, all relative paths in ansible.cfg are relative to the file itself, it does provde a {{CWD}} macro for those wanting that behaviour.

'playbook' related path might not work as you can have/pass multiple playbooks to ansible and many of the settings need to be purely global and cannot change in the middle of a run, those that can should already have facilities to do so either automatically or via in play keywords or variables.

[ssbarnea]

@bcoca I am really glad to hear that 2.4 did the right thing. I missed to read this in Ansible 2.4 release notes and migration guidelines so I expect few surprised users. For me is a good reason to speedup transition to 2.4 which should be an easy one.

[dagwieers]

@bcoca we were using yesterday's devel branch and ansible-playbook and ansible behaved differently. i.e. ansible-playbook was looking for action plugins in playbook location, not ansible.cfg location. ansible instead relied on config location.

[bcoca]

@dagwieers because ansible does not have a 'playbook location', ansible-playbook should be looking at BOTH locations, playbook/role locations take priority over configuration locations.

docs .. WIP ... will get there https://github.com/ansible/ansible/pull/30560

[ssbarnea]

@bcoca I think that it does as I am using the {{ playbook_dir }} in few places, but again, that's for use inside playbooks. I agree with you that it does not make any sense to use it in ansible.cfg because at the moment the config is loaded there is no playbook, and in same use cases it will never be one.

[bcoca]

@ssbarnea so with 2.4.1 we get the behaviour I described above: {{CWD}} macro + ansible.cfg location being the default for all relative paths.

Should we consider this proposal "done"?

[ssbarnea]

@bcoca Yep, if the default behaviour of ansible >=2.4.1 would be to use paths relative to the config file itself I am more than happy. The CWD macro could be used by the (very) few people that would want to stick to the old unreliable behaviour.

Thank you for fixing this long stating issue!