Skip to content
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

Closed
tkellen opened this issue Jun 4, 2015 · 41 comments
Closed

ansible.cfg lookup paths for ansible-playbook #11175

tkellen opened this issue Jun 4, 2015 · 41 comments
Assignees

Comments

@tkellen
Copy link
Contributor

@tkellen 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."
@srgvg
Copy link
Member

@srgvg 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
Copy link
Contributor Author

@tkellen 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
Copy link
Contributor Author

@tkellen 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
Copy link
Member

@bcoca bcoca commented Jun 5, 2015

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

@srgvg
Copy link
Member

@srgvg srgvg commented Jun 5, 2015

@bcoca +1

@sivel
Copy link
Member

@sivel sivel commented Jun 5, 2015

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

@bcoca
Copy link
Member

@bcoca bcoca commented Jun 5, 2015

but I can add BIG DEPRECATION warning ....

@sivel
Copy link
Member

@sivel 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
Copy link
Member

@bcoca 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
Copy link
Contributor Author

@tkellen 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
Copy link
Member

@srgvg 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
Copy link
Member

@bcoca 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
Copy link
Member

@sivel sivel commented Jun 9, 2015

I think that should suffice.

@tkellen

This comment was marked as off-topic.

@srgvg
Copy link
Member

@srgvg 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
* 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
Copy link
Contributor Author

@tkellen tkellen commented Aug 17, 2015

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

@thenavs

This comment was marked as off-topic.

1 similar comment
@jeffwidman

This comment was marked as off-topic.

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

This comment was marked as off-topic.

@rjayatilleka

This comment was marked as off-topic.

@guilhermeblanco
Copy link

@guilhermeblanco 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 was marked as off-topic.

@yourwebmaker

This comment was marked as off-topic.

@mamoit

This comment was marked as off-topic.

@akamensky
Copy link
Contributor

@akamensky 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
Copy link
Contributor

@akamensky akamensky commented Aug 17, 2016

@bcoca @srvg

Sent PR, please check if that will be okay.

@ansibot

This comment has been hidden.

@cjw296
Copy link

@cjw296 cjw296 commented Apr 4, 2017

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

@bencoughlan
Copy link

@bencoughlan 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
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
@bcoca
Copy link
Member

@bcoca bcoca commented May 14, 2019

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

@bcoca bcoca closed this May 14, 2019
@jamesongithub
Copy link

@jamesongithub jamesongithub commented May 14, 2019

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

@bcoca
Copy link
Member

@bcoca bcoca commented May 14, 2019

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.

@ansible ansible locked and limited conversation to collaborators Aug 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

You can’t perform that action at this time.