cancel
Showing results for 
Search instead for 
Did you mean: 
DNAtsol_student
Flight Engineer
Flight Engineer
  • 225 Views

Ansible settings files. Do they add/change or completely replace...

Jump to solution

Hey All, 

going thorugh DO457 right now and in Chapter 2 they discuss how ansible config files  (ansible.cfg) can be in several locations (i.e., /etc/ansible/ansible.cfg, ~./.ansible/ansible.cfg). 

The text intimates that if there are config files in both locations, the first place it is found is the file that is used. It's not explicitly stated, but I'm hypothesisizing this because in the previous section it talks about how ansible-navigator settings files can be defined in one of 3 places, it looks for the file in a specific order and stops looking after finding one (sort of like reading an ACL??). 

is this an accurate understanding? 

Another thought I had was that it might work in a similar way to how profiles configs work, where there is a system wide profile in /etc/ and if there is a .profile file in the user's home directory it overwrites settings that are common and adds settings that are unique to that user (the example and exercise that is used in RH124 is the changing of default permissions). 

 

Does anyone know which interpretation is accurate? I don't have ansible setup on my home system so I can't currently investigate this myself. 

 

Thanks for any insight and thoughts. 

Labels (3)
1 Solution

Accepted Solutions
ricardodacosta
Moderator
Moderator
  • 219 Views

Ansible's configuration directives work on the principal of merging directives. In the event of a conflict, the directive set in the location with the highest precedence wins. 

Starting with the highest precedence:

(1) ANSIBLE_CONFIG=my_ansible.cfg

(2) ./ansible.cfg

(3) ~/.ansible.cfg

(4) /etc/ansible/ansible.cfg

 

If (4) declares `foo=bar` and nothing else declares `foo`, then the value of `foo` will be `bar`.

If (4) declares `foo=bar` and (3) declares `foo=baz` and (2) declares `foo=bongle` then the value of `foo` will be `bongle`

All non-conflicting directives are still read from lower priority sources.

See `ansible-config dump` where the green directives are labelled as `default` are implicit, default configurations which don't have to be explicitly set. Non-defaults are colourised in yellow and the source for the directive is within parentheses.

 

 

View solution in original post

6 Replies
ricardodacosta
Moderator
Moderator
  • 220 Views

Ansible's configuration directives work on the principal of merging directives. In the event of a conflict, the directive set in the location with the highest precedence wins. 

Starting with the highest precedence:

(1) ANSIBLE_CONFIG=my_ansible.cfg

(2) ./ansible.cfg

(3) ~/.ansible.cfg

(4) /etc/ansible/ansible.cfg

 

If (4) declares `foo=bar` and nothing else declares `foo`, then the value of `foo` will be `bar`.

If (4) declares `foo=bar` and (3) declares `foo=baz` and (2) declares `foo=bongle` then the value of `foo` will be `bongle`

All non-conflicting directives are still read from lower priority sources.

See `ansible-config dump` where the green directives are labelled as `default` are implicit, default configurations which don't have to be explicitly set. Non-defaults are colourised in yellow and the source for the directive is within parentheses.

 

 

DNAtsol_student
Flight Engineer
Flight Engineer
  • 184 Views

Thanks! That clarifies things immensely. 

One final point of clarification: (2) ./ansible.cfg would be the config file specifc to a project?? 

Also, just to make sure I understand order of precedence: 

If (1) is defined and uses '/etc/ansible/ansible.cfg' as it's value, then 'foo' will be 'bar' even if (2) has "foo=bongle" and  (4) is technically lower on the precedence order,  because (1) has the highest order precedence and it is defining the file that is to be used (which in this case is the file defined in (4)).

 

I think I just hurt my head    . 

0 Kudos
ricardodacosta
Moderator
Moderator
  • 85 Views

One final point of clarification: (2) ./ansible.cfg would be the config file specifc to a project??

Yeah - you would typically store `./ansible.cfg` in your git repo with your playbook(s). When developing for Automation Controller, you won't be able to take advantage of `/etc/ansible/ansible.cfg` and `~/.ansible.cfg`

If (1) is defined and uses '/etc/ansible/ansible.cfg' as it's value, then 'foo' will be 'bar' even if (2) has "foo=bongle" and  (4) is technically lower on the precedence order,  because (1) has the highest order precedence and it is defining the file that is to be used (which in this case is the file defined in (4)).

Interesting take on rearranging things but yeah, you're right. `ANSIBLE_CONFIG` becomes the authority in that scenario.

 

0 Kudos
DNAtsol_student
Flight Engineer
Flight Engineer
  • 47 Views

fair point  

Probably not "best practice", but I just wanted to use your existing example to work through my level of comprehension . 

 

Also appreciate that insight into ansible.cfg file in /etc/ and ~./ not being available to Automation Controllers. 

 

0 Kudos
DNAtsol_student
Flight Engineer
Flight Engineer
  • 182 Views

Just as a fun quick followup, I did a ansible-config dump

and saw this at the top: : ANSIBLE_COW_ACCEPTLIST(default) = ['bud-frogs', 'bunny', 'cheese', 'daemon', 'default', 'dragon', 'elephant-in-snake' .... impy', 'supermilker', 'three-eyes', 'turkey', 'turtle', 'tux', 'udder', 'vader-koala', 'vader', 'www']

It's nice to know folks are still having a bit of fun when working on this stuff  

ricardodacosta
Moderator
Moderator
  • 85 Views

It can't be all work and no play!

 

Join the discussion
You must log in to join this conversation.