cmueller/ansible
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

[Doc] Update Conditional Imports (#35492)

Browse source 
* [Doc] Update Conditional Imports

facter/ohai is not needed for the ansible internal facts
also fix that os_family for centos is redhat

* Copy edit.
This commit is contained in:
Klaas Demter 2018-02-20 21:12:12 +01:00 committed by scottb
parent 75ab070c63
commit ce80485ecd
1 changed files with 8 additions and 19 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

27
docs/docsite/rst/user_guide/playbooks_conditionals.rst
View file

@ -220,30 +220,19 @@ but it is easily handled with a minimum of syntax in an Ansible Playbook::
As a reminder, the various YAML files contain just keys and values:: As a reminder, the various YAML files contain just keys and values::
--- ---
# for vars/CentOS.yml # for vars/RedHat.yml
apache: httpd apache: httpd
somethingelse: 42 somethingelse: 42
How does this work? If the operating system was 'CentOS', the first file Ansible would try to import How does this work? For Red Hat operating systems ('CentOS', for example), the first file Ansible tries to import
would be 'vars/CentOS.yml', followed by '/vars/os_defaults.yml' if that file is 'vars/RedHat.yml'. If that file does not exist, Ansible attempts to load 'vars/os_defaults.yml'. If no files in
did not exist. If no files in the list were found, an error would be raised. the list were found, an error is raised.
On Debian, it would instead first look towards 'vars/Debian.yml' instead of 'vars/CentOS.yml', before
falling back on 'vars/os_defaults.yml'. Pretty simple.
To use this conditional import feature, you'll need facter or ohai installed prior to running the playbook, but On Debian, Ansible first looks for 'vars/Debian.yml' instead of 'vars/RedHat.yml', before
you can of course push this out with Ansible if you like:: falling back on 'vars/os_defaults.yml'.
# for facter Ansible's approach to configuration -- separating variables from tasks, keeping your playbooks
ansible -m yum -a "pkg=facter state=present" from turning into arbitrary code with nested conditionals - results in more streamlined and auditable configuration rules because there are fewer decision points to track.
ansible -m yum -a "pkg=ruby-json state=present"
# for ohai
ansible -m yum -a "pkg=ohai state=present"
Ansible's approach to configuration -- separating variables from tasks, keeps your playbooks
from turning into arbitrary code with ugly nested ifs, conditionals, and so on - and results
in more streamlined & auditable configuration rules -- especially because there are a
minimum of decision points to track.
Selecting Files And Templates Based On Variables Selecting Files And Templates Based On Variables
```````````````````````````````````````````````` ````````````````````````````````````````````````