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

Merge pull request #1429 from nigelm/nigelm_doc_tweaks

Browse source 
Fix $last_result documentation and spelling tweaks - issue #1420
This commit is contained in:
Michael DeHaan 2012-10-23 21:01:45 -07:00
commit bfa66ba9ed
1 changed files with 5 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
docsite/rst/playbooks2.rst
View file

@ -127,7 +127,7 @@ period.
Don't worry about any of this unless you think you need it. You'll know when you do. Don't worry about any of this unless you think you need it. You'll know when you do.
Variable File Seperation Variable File Separation
```````````````````````` ````````````````````````
It's a great idea to keep your playbooks under source control, but It's a great idea to keep your playbooks under source control, but
@ -262,11 +262,11 @@ One common useful trick with only_if is to key off the changed result of a last
tasks: tasks:
- action: template src=/templates/foo.j2 dest=/etc/foo.conf - action: template src=/templates/foo.j2 dest=/etc/foo.conf
register: last_result
- action: command echo 'the file has changed' - action: command echo 'the file has changed'
only_if: '${last_result.changed}' only_if: '${last_result.changed}'
$last_result is a variable automatically set by Ansible, and it is a boolean, so there is no need $last_result is a variable set by the register directive. This assumes Ansible 0.8 and later.
to test for it against something else with an explicit equals. This assumes Ansible 0.8 and later.
In Ansible 0.8, a few shortcuts are available for testing whether a variable is defined or not:: In Ansible 0.8, a few shortcuts are available for testing whether a variable is defined or not::
@ -334,7 +334,7 @@ you can of course push this out with Ansible if you like::
# for ohai # for ohai
ansible -m yum -a "pkg=ohai ensure=installed" ansible -m yum -a "pkg=ohai ensure=installed"
Ansible's approach to configuration -- seperating variables from tasks, keeps your playbooks 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 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 in more streamlined & auditable configuration rules -- especially because there are a
minimum of decision points to track. minimum of decision points to track.
@ -512,7 +512,7 @@ A script for setting up ansible-pull is provided in the examples/playbooks direc
checkout. checkout.
The basic idea is to use Ansible to set up a remote copy of ansible on each managed node, each set to run via The basic idea is to use Ansible to set up a remote copy of ansible on each managed node, each set to run via
cron and update playbook source via git. This interverts the default push architecture of ansible into a pull cron and update playbook source via git. This inverts the default push architecture of ansible into a pull
architecture, which has near-limitless scaling potential. The setup playbook can be tuned to change architecture, which has near-limitless scaling potential. The setup playbook can be tuned to change
the cron frequency, logging locations, and parameters to ansible-pull. the cron frequency, logging locations, and parameters to ansible-pull.