ansible.cfg lookup paths for ansible-playbook #11175

Open
tkellen opened this Issue Jun 4, 2015 · 35 comments

Projects

None yet
@tkellen
Contributor
tkellen commented Jun 4, 2015

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)
  • /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.

@tkellen tkellen referenced this issue in bocoup/deployment-workflow Jun 4, 2015
Merged

Addressing #20. #23

@srvg
Member
srvg commented Jun 5, 2015

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
Contributor
tkellen commented Jun 5, 2015

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
Contributor
tkellen commented Jun 5, 2015

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
Member
bcoca commented Jun 5, 2015

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

@srvg
Member
srvg commented Jun 5, 2015

@bcoca +1

@sivel
Member
sivel commented Jun 5, 2015

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

@bcoca
Member
bcoca commented Jun 5, 2015

but I can add BIG DEPRECATION warning ....

@sivel
Member
sivel commented Jun 6, 2015

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
Member
bcoca commented Jun 6, 2015

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

@tkellen
Contributor
tkellen commented Jun 9, 2015

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

@srvg
Member
srvg commented Jun 9, 2015

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
Member
bcoca commented Jun 9, 2015

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
Member
sivel commented Jun 9, 2015

I think that should suffice.

@tkellen
Contributor
tkellen commented Jun 9, 2015

πŸ‘

@srvg
Member
srvg commented Jun 9, 2015

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?

@cowboy cowboy added a commit to bocoup/deployment-workflow that referenced this issue Jun 15, 2015
@cowboy cowboy Move ansible.cfg to project root.
* See related issue ansible/ansible#11175
* ansible-playbook will need to be run from the project root for
  ssh agent forwarding (defined in ansible.cfg) to work.
3a40842
@tkellen
Contributor
tkellen commented Aug 17, 2015

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

@thenavs
thenavs commented Sep 1, 2015

πŸ‘

@jeffwidman
Contributor

πŸ‘

@jimi-c jimi-c removed the P3 label Dec 7, 2015
@kazesberger

πŸ‘

@rjayatilleka

+1

@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.

@marksteele

What @guilhermeblanco said. πŸ‘

@mamoit
mamoit commented May 3, 2016

πŸ‘

@mauricios

πŸ‘

@tkellen tkellen referenced this issue in bocoup/deployment-workflow May 11, 2016
Closed

ansible.cfg removed but not from docs #92

@cjw296
cjw296 commented May 17, 2016

πŸ‘ from me! Also, where is the current search path documented? I'd expect it on http://docs.ansible.com/ansible/intro_configuration.html but I must be missing something?

@amadornimbis

@cjw296 It is documented at the very top of the link you posted:

Changes can be made and used in a configuration file which will be processed in the following order:

* ANSIBLE_CONFIG (an environment variable)
* ansible.cfg (in the current directory)
* .ansible.cfg (in the home directory)
* /etc/ansible/ansible.cfg

Prior to 1.5 the order was:

* ansible.cfg (in the current directory)
* ANSIBLE_CONFIG (an environment variable)
* .ansible.cfg (in the home directory)
* /etc/ansible/ansible.cfg
@cjw296
cjw296 commented Jun 9, 2016

@amadornimbis - thanks for correcting my blindness :-)

@akamensky

Coming from #17087 which was closed as dupe:

So this issue is known and has been around for over a year and still no PR for this?

Is it still considered as a valid proposal?

@akamensky
akamensky commented Aug 16, 2016 edited

Looking at the source code lib/ansible/constants.py I find it pretty difficult to do this change and keep the code sane.

The issue is that load_config_file() is called on import time, thus the CLI arguments are not parsed yet. And the reference to playbook file may be on any position of sys.argv.

I see two possible solutions:

  1. To make it work reliably I will have to parse all arguments right there skipping those that can point to other files (such as --extra-vars, --inventory-file, --vault-password-file and other). That will make it rather unstable (add new argument pointing to another file and it is broken) and ridiculously complex.
  2. Lookup for ansible.cfg in sibling directories only when playbook is found at sys.argv[1]. That will make it somewhat more reliable and keep the code sane.
  3. Completely overhaul initialization process to be aware of CLI arguments before we get to loading config file (circular dependency right there, isn't it?)

Any thoughts on those? @bcoca @srvg

I am inclined towards option number 2 as it is simplest and most sane one of all 3. If there is any support for this change I can send a PR.

@bcoca
Member
bcoca commented Aug 16, 2016 edited

\4. Create new config.yml that is not CWD dependent, is 'upwards mergable' and can be referenced/added from play and/or can be merged/overriden from roles/meta/config.yml

@akamensky

Good option but will closely resemble option 3. Will need a major overhaul. Guess that is more like for v3 changeset.

Then also:

\5. To create new CLI argument for getting config file from random location (--config-file <file>)

@bcoca
Member
bcoca commented Aug 16, 2016

not a switch but you can set the env var in the command line:

ANSIBLE_CONFIG=/path ansible-playbook ....

@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.

@ansibot ansibot added the affects_2.0 label Sep 8, 2016
@xenithorb xenithorb referenced this issue in ansible/ansible-modules-core Sep 29, 2016
Closed

apt update_cache gives error on ubuntu for Ansible 2.0.0.2 #2951

@ansibot ansibot added the affects_2.3 label Dec 13, 2016
@jimi-c jimi-c added the c:cli/ label Jan 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment