New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ansible.cfg lookup paths for ansible-playbook #11175

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

Comments

Projects
None yet
@tkellen
Contributor

tkellen commented Jun 4, 2015

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

@tkellen tkellen referenced this issue Jun 4, 2015

Merged

Addressing #20. #23

@srgvg

This comment has been minimized.

Member

srgvg 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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Member

bcoca commented Jun 5, 2015

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

@srgvg

This comment has been minimized.

Member

srgvg commented Jun 5, 2015

@bcoca +1

@sivel

This comment has been minimized.

Member

sivel commented Jun 5, 2015

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

@bcoca

This comment has been minimized.

Member

bcoca commented Jun 5, 2015

but I can add BIG DEPRECATION warning ....

@sivel

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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!

@srgvg

This comment has been minimized.

Member

srgvg 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

This comment has been minimized.

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

This comment has been minimized.

Member

sivel commented Jun 9, 2015

I think that should suffice.

@tkellen

This comment has been minimized.

Contributor

tkellen commented Jun 9, 2015

👍

@srgvg

This comment has been minimized.

Member

srgvg 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 added a commit to bocoup/deployment-workflow that referenced this issue Jun 15, 2015

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

This comment has been minimized.

Contributor

tkellen commented Aug 17, 2015

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

@thenavs

This comment has been minimized.

thenavs commented Sep 1, 2015

👍

1 similar comment
@jeffwidman

This comment has been minimized.

Contributor

jeffwidman commented Sep 26, 2015

👍

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

@kazesberger

This comment has been minimized.

kazesberger commented Jan 14, 2016

👍

@rjayatilleka

This comment has been minimized.

rjayatilleka commented Feb 22, 2016

+1

@guilhermeblanco

This comment has been minimized.

guilhermeblanco commented Feb 27, 2016

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

This comment has been minimized.

marksteele commented Feb 27, 2016

What @guilhermeblanco said. 👍

@yourwebmaker

This comment has been minimized.

yourwebmaker commented Feb 29, 2016

@mamoit

This comment has been minimized.

mamoit commented May 3, 2016

👍

@cjw296

This comment has been minimized.

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

This comment has been minimized.

amadornimbis commented Jun 7, 2016

@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

This comment has been minimized.

cjw296 commented Jun 9, 2016

@amadornimbis - thanks for correcting my blindness :-)

@akamensky

This comment has been minimized.

akamensky commented Aug 16, 2016

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

This comment has been minimized.

akamensky commented Aug 16, 2016

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

This comment has been minimized.

Member

bcoca commented Aug 16, 2016

\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

This comment has been minimized.

akamensky commented Aug 16, 2016

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

This comment has been minimized.

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

This comment has been minimized.

akamensky commented Aug 16, 2016

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

This comment has been minimized.

akamensky commented Aug 17, 2016

@bcoca @srvg

Sent PR, please check if that will be okay.

@ansibot

This comment has been minimized.

Contributor

ansibot commented Apr 4, 2017

@tkellen Greetings! Thanks for taking the time to open this issue. In order for the community to handle your issue effectively, we need a bit more information.

Here are the items we could not find in your description:

  • ansible version
  • component name

Please set the description of this issue with this template:
https://raw.githubusercontent.com/ansible/ansible/devel/.github/ISSUE_TEMPLATE.md

click here for bot help

@cjw296

This comment has been minimized.

cjw296 commented Apr 4, 2017

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

@bencoughlan

This comment has been minimized.

bencoughlan commented May 4, 2017

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

gerrit-ovirt-org pushed a commit to oVirt/ovirt-hosted-engine-setup that referenced this issue Jan 10, 2018

ansible: make ansible-playbook logging
make ansible-playbook logging via ANSIBLE_LOG_PATH
env variable.
Unfortunately we cannot use a single ansible.cfg file
in our playbooks directory due to
ansible/ansible#11175
We cannot neither use plain ansible logger facility
since it's just based on utils/display.py
See:
ansible/ansible#25761 (comment)

Current log format is really poor, we have more details
in the extra dicitonay but we are not writing it.
There is no filtering at all for sensitive information.


Change-Id: Idc9eb76ea295462e51ca32fd376946c15d44ef56
Signed-off-by: Simone Tiraboschi <stirabos@redhat.com>

@ansibot ansibot added feature and removed feature_idea labels Mar 2, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment