ansible.cfg lookup paths for ansible-playbook

[tkellen]

ISSUE TYPE

Feature Idea

COMPONENT NAME

ansible.cfg

ANSIBLE VERSION

N/A

SUMMARY

Would ya'll be open to a PR that adds a new location for finding ansible.cfg?
I would like for ansible-playbook to search sibling to the playbook being used. I think it should be possible to run ansible-playbook from any directory without modifying global or per-user configuration files and have customized ansible.cfg settings respected.
I'm proposing a lookup precedence of:

• ANSIBLE_CONFIG (an environment variable)
• ansible.cfg (in the current directory)
• ansible.cfg (sibling to the playbook when ansible-playbook is used)
• .ansible.cfg (in the home directory)\n- /etc/ansible/ansible.cfg
  I understand this wouldn't make sense for the ansible command, but I'm hopeful that isn't considered an issue."

[srgvg]

On 5 June 2015 at 00:16, Tyler Kellen notifications@github.com wrote:

ansible.cfg (sibling to the playbook when ansible-playbook is used)

​Given an ansible.cfg is often tightly related to the project, I think this
makes a lot of sense.

Configuration of ansible should be part of the playbook scripts. (I
actually never understood the use case for having /etc/ansible/, which imho
ius more tight to the root account than being some global default, but that
is another story)
I actually always put ansible.cfg in my playbooks repo root, and cd into
there to run things.​

One thing to consider though, might be how that extra path looks like in
case of playbook includes?

I often have my global playbook as ./main.yml which includes playbooks from
./playbooks/*.yml.
Which path would be considered here, given I'd like the same config to be
applied if I run main.yml and a specific playbook in ./playbook/?

-- Serge

[tkellen]

Perhaps this should be augmented to traverse from the playbook directory upwards until an ansible.cfg is found? I also wish you could control all of these options from a playbook rather than having an extra config file, but that seems like a much larger technical hurdle (I've looked into the codebase to attempt this for a few specific options).

[tkellen]

It could also be an option in the playbook itself, to reference the relevant ansible.cfg. I believe this would require re-spawning the process though.

Basically, I'm looking for any guidance for what would be an acceptable solution to solve this:

I think it should be possible to run ansible-playbook from any directory without modifying global or per-user configuration files and have customized ansible.cfg settings respected.

[bcoca]

actually, I don't think 'current directory' should be picked up, it should have always been 'play adjacent'

[srgvg]

@bcoca +1

[sivel]

Current directory shouldn't be changed though. Changing it would likely causes issues at this point

[bcoca]

but I can add BIG DEPRECATION warning ....

[sivel]

Doing so would have a negative affect on the ansible ad-hoc command which has no playbook.

Also I have a set of playbooks which I use for various customers that are actually all the same, but I have individual directories with ansible.cfg files that I to perform my execution from.

My other primary environment has a site.yml in the root, and all other playbooks in a playbooks directory. I don't always run site.yml, this would require me to symlink, which would also make it more complicated for my team, since the ansible.cfg is not part of the repo, due to individual differences.

Not sure there is really a problem with leaving it around. Just want to make sure I provide some additional context and use cases.

[bcoca]

@sivel my concern is that this can become a security issue pretty fast ( cd /tmp; asnible.cfg with roles pointing to suspect code ....)

[tkellen]

Deprecation of the existing functionality or not, it would be a huge boon to my team if this could be added in some fashion!

[srgvg]

I could perhaps live with deprecating the current directory, but only if good alternatives exist. I know of a couple of projects that rely on this functionality (e.g. stackforge/openstack-ansible-deployment).

Whilst adjacent to the playbook makes a lot more sense (some options change behaviour of playbooks, e.g. the merge dict option), let's keep in mind a lot of projects do playbook includes from other directories, and all of those playbooks might need the link to that config. So this should be thought through very well. Should we take into account all the basedir's? Only the one from the called playbook can be dangerous.

Now I think of it, the example of the hash_behaviour option, really should be a play option. Perhaps other I don't know or think of, too. Play execution should not change depending on some global option that is set unrelated to the playbooks. (Which already is a problem when writing roles... which hash_behaviour should be taken into account when writing roles?)

[bcoca]

ok, going back to the original issue ... ansible.cfg search locations, I'm good with following the list in the original post, but would like to check for 'world writable' directory for 'cwd' for any ansible.cfg location and issue a warning.

^ does that work for everyone?

[sivel]

I think that should suffice.

[srgvg]

Do you mean only looking at the path of the playbook given to ansible-playbook? Which would then break if one was to target directly an playbook that the former includes from another directory?

[tkellen]

Say, is this going to become a reality in Ansible 2.0?

[guilhermeblanco]

This support would allow a substantial improvement towards reusability and segregation of roles.
Currently my ideal setup is blocked until this enhancement get added, but it's worth sharing my line of thinking to others.

Here is what I consider an ideal configuration:

+ ansible
|-+ environments
| |-+ staging
| | |-+ group_vars
| | | |-- all
| | | `-- webservers
| | |-+ host_vars
| | | `-- api01
| | |-+ roles
| | | `-+ environment_specific_roles
| | |   `-- ...
| | |-- inventory
| | |-- site.yml
| | |-- ansible.cfg
| | |-- webserver.yml
| | `-- another_tier.yml
| `-+ production
|   `-- ...
|-+ roles
| `-- ...
|-- shared_tier.yml
`-- common.yml

ansible.cfg file would be:

[defaults]
inventory  = /path/to/ansible/environments/staging/inventory
roles_path = /path/to/ansible,/path/to/ansible/environments/staging

Running:

ansible-playbook -i environments/production/inventory environments/production/site.yml --limit <tier> -v

Simpler environments would just benefit of what we have today as "ansible.cfg (in the current directory)" and would work nicely.

Huge 👍 for this built-in in Ansible.

[akamensky]

Righto, then strike option 5.

Still think that as a temporary solution number 2 should work fine. Option 4 is good, but that is too big of a change for same major version IMO.

I will prepare the PR for this. The change should be pretty minimal.

[akamensky]

@bcoca @srvg

Sent PR, please check if that will be okay.

[cjw296]

@jimi-c - take @ansibot home, it's drunk again...

[bencoughlan]

Any update on this? It seems like a big gap that I can't specify it in the cli.

[bcoca]

closing as paths are not going to change at this point for ansible.cfg.

But keeping this in mind if we ever switch to a new yaml based config file

[jamesongithub]

curious what does the format of the cfg file have to do w/ the path?

[bcoca]

re implementing how config works to be mergeable and hierarchical gives the me license of setting a new 'discovery path' and leave the current ansible.cfg as for those that don't want to move to the new option.