You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At this moment ansible looks for ansible.cfg only on current folder before trying to to look for user or system config ones. This means that if you have a project specific ansible.cfg file, you will be able to use it only when your CWD is matching your project root. Otherwise, ansible will fail to load the project specific config file and will endup using the user or system one.
This is extreamly easy to test with ansible --version which displays the loaded config, just cd 'subfolder' and run it again.
Most tools I know are able to detect the location of project specific configuration by also looking at parents of CWD.
Examples: tox, pylint, flake, pre-commit, ....
Problems
One problem that is clearly sorted by this new behavior is that it enables developers to put playbooks in subfolders in their projects or to move them around without breaking them.
Also this allows them to call their playbooks from any subfolder of their projects without risking of breaking them.
One of the most common directory structure in repositories using ansible code is to have a roles/ folder and a playbooks/ folder (nobody wants to keep playbooks in root of their repos--- it does not scale). This popular setup has one inconvenience: user is forced to CD to project root and call playbooks with their full paths (or role inclusion would fail): ansible-playbook playbooks/foo.yml.
This also means that if users want to make playbooks executable using a shebang like #!/usr/bin/env ansible-playbook they would soon discover that they can call them only when they are in the right folder, or role inclusion would again fail (just because ansible loads a different ansible.cfg when called from another folder).
Once ansible will discover ansible.cfg from parent folders, this will be sorted and people could call the playbooks regardless if they are inside ~/project or ~/project/foo or ~/project/foo/bar folders.
Testing
To avoid regressions a minimal test suite should be added. It very easy to test because the new behavior allows user to use relate role location. Once implemented a user could call a playbooks from a subfolder and relative role_paths would work, because they are relative to the configuration file (which now will be the same, located in parent folder)
Documentation
Documentation needs to be updated to include the parent lookup behavior.
Anything else?
This change should not lower the security of Ansible because we already have a security measure of not-loading ansible.cfg files from folders that are world-writable. The same rule would apply when checking parent folders.
There is a very small performance price to pay related to navigating to parent folders but that is minimal and happens only once.
The text was updated successfully, but these errors were encountered:
Proposal: improve ansible.cfg location discovery
Author: Sorin Sbarnea <@ssbarnea> IRC: zbr
Date: 2019-06-21
Motivation
At this moment ansible looks for
ansible.cfg
only on current folder before trying to to look for user or system config ones. This means that if you have a project specific ansible.cfg file, you will be able to use it only when your CWD is matching your project root. Otherwise, ansible will fail to load the project specific config file and will endup using the user or system one.This is extreamly easy to test with
ansible --version
which displays the loaded config, just cd 'subfolder' and run it again.Most tools I know are able to detect the location of project specific configuration by also looking at parents of CWD.
Examples: tox, pylint, flake, pre-commit, ....
Problems
One problem that is clearly sorted by this new behavior is that it enables developers to put playbooks in subfolders in their projects or to move them around without breaking them.
Also this allows them to call their playbooks from any subfolder of their projects without risking of breaking them.
One of the most common directory structure in repositories using ansible code is to have a
roles/
folder and aplaybooks/
folder (nobody wants to keep playbooks in root of their repos--- it does not scale). This popular setup has one inconvenience: user is forced to CD to project root and call playbooks with their full paths (or role inclusion would fail):ansible-playbook playbooks/foo.yml
.This also means that if users want to make playbooks executable using a shebang like
#!/usr/bin/env ansible-playbook
they would soon discover that they can call them only when they are in the right folder, or role inclusion would again fail (just because ansible loads a different ansible.cfg when called from another folder).Once ansible will discover ansible.cfg from parent folders, this will be sorted and people could call the playbooks regardless if they are inside
~/project
or~/project/foo
or~/project/foo/bar
folders.Testing
To avoid regressions a minimal test suite should be added. It very easy to test because the new behavior allows user to use relate role location. Once implemented a user could call a playbooks from a subfolder and relative role_paths would work, because they are relative to the configuration file (which now will be the same, located in parent folder)
Documentation
Documentation needs to be updated to include the parent lookup behavior.
Anything else?
This change should not lower the security of Ansible because we already have a security measure of not-loading ansible.cfg files from folders that are world-writable. The same rule would apply when checking parent folders.
There is a very small performance price to pay related to navigating to parent folders but that is minimal and happens only once.
The text was updated successfully, but these errors were encountered: