whitespace

examples/playbooks/ansible_pull.yml

-# ansibple-pull setup 
+# ansibple-pull setup
 #
 # on remote hosts, set up ansible to run periodically using the latest code
 # from a particular checkout, in pull based fashion, inverting Ansible's
-# usual push-based operating mode.  
+# usual push-based operating mode.
 #
 # This particular pull based mode is ideal for:
 #
@@ -12,7 +12,7 @@
 # DO NOT RUN THIS AGAINST YOUR HOSTS WITHOUT CHANGING THE repo_url
 # TO SOMETHING YOU HAVE PERSONALLY VERIFIED
 #
-# 
+#
 ---
 
 - hosts: pull_mode_hosts

examples/playbooks/conditionals_part1.yml

@@ -37,7 +37,7 @@
 # and this is just a regular task line from a playbook, as we're used to.
 # but with variables in it that come from above.  Note that the variables
 # from above are *also* available in templates
-     
+
   tasks:
 
   - name: ensure apache is latest
@@ -47,5 +47,5 @@
   - name: fail
     action: command /bin/false
 
- 
+
 

examples/playbooks/conditionals_part2.yml

@@ -16,9 +16,9 @@
 # extraordinarily clean, and not littered with programming language
 # constructs -- so it's easily skimmed by humans.
 #
-# Remember to quote any variables if they are not numbers!  
+# Remember to quote any variables if they are not numbers!
 #
-# Interesting fact: aside from the $variables, these expressions are actually 
+# Interesting fact: aside from the $variables, these expressions are actually
 # tiny bits of Python.  They are evaluated in the context of each host, so different
 # steps can be skipped on different hosts!  They should evaluate to either True
 # or False
@@ -40,7 +40,7 @@
      - name: "do this if my favcolor is blue"
        action: shell /bin/false
        only_if: '$is_favcolor_blue'
-     
+
      - name: "do this if my favcolor is not blue"
        action: shell /bin/true
        only_if: 'not ($is_favcolor_blue)'

examples/playbooks/intermediate_example.yml

 ---
 # see examples.yml first!
-# This file explains some more advanced features of playbooks.  
+# This file explains some more advanced features of playbooks.
 # because of the comments it's less concise than it normally is.  But feel
 # free to comment your playbooks if you like.
 
@@ -34,12 +34,12 @@
 
   # we could also have done something like:
   # - include: wordpress.yml user=timmy
-  # and had access to the template variable $user in the 
+  # and had access to the template variable $user in the
   # included file, if we wanted to.  Variables from vars
   # and vars_files are also available inside include files
 
   handlers:
- 
+
     # handlers can also be included from files, to promote reuse
     # and simpler recipes, you may wish to only have one
     # handler file for all your plays and playbooks
@@ -70,7 +70,7 @@
   # vars must be specified again for the next play in the playbook
   # but can be reused by including from vars_files if you want
   # you can use vars, vars_files, or both.  vars_files overrides
-  # those set in vars. 
+  # those set in vars.
 
   vars:
      release: 2.0

examples/playbooks/intro_example.yml

@@ -38,9 +38,9 @@
   # let's demo file operations.
   #
   # We can 'copy' files or 'template' them instead, using jinja2
-  # as the templating engine.  This is done using the variables 
-  # from the vars section above mixed in with variables bubbled up 
-  # automatically from tools like facter and ohai.  'copy' 
+  # as the templating engine.  This is done using the variables
+  # from the vars section above mixed in with variables bubbled up
+  # automatically from tools like facter and ohai.  'copy'
   # works just like 'template' but does not do variable subsitution.
   #
   # If and only if the file changes, restart apache at the very

examples/playbooks/mysql.yml

@@ -18,4 +18,4 @@
       action: mysql_db loginpass=$mysql_root_password db=bobdata state=present
 
     - name: Ensure no user named 'sally' exists
-      action: mysql_user loginpass=$mysql_root_password user=sally state=absent
+      action: mysql_user loginpass=$mysql_root_password user=sally state=absent
\ No newline at end of file

examples/playbooks/nested_playbooks.yml

@@ -8,7 +8,7 @@
 # the tag feature and can be used in conjunction for very fine grained
 # control over what you want to target when running ansible.
 
-- name: this is a play at the top level of a file  
+- name: this is a play at the top level of a file
   hosts: all
   user: root
   tasks:

examples/playbooks/postgresql.yml

@@ -35,4 +35,4 @@
     action: postgresql_db db=$dbname
 
   - name: ensure user has access to database
-    action: postgresql_user db=$dbname user=$dbuser password=$dbpassword
+    action: postgresql_user db=$dbname user=$dbuser password=$dbpassword
\ No newline at end of file

examples/playbooks/prompts.yml

@@ -22,7 +22,7 @@
 # vars_prompt:
 #   release_version: "product release version"
 
-# prompts can also be specified like this, allowing for hiding the prompt as 
+# prompts can also be specified like this, allowing for hiding the prompt as
 # entered.  In the future, this may also be used to support crypted variables
 
   vars_prompt:

examples/playbooks/selective_file_sources.yml

@@ -2,7 +2,7 @@
 # this is an example of how to template a file over using some variables derived
 # from the system.  For instance, if you wanted to have different configuration
 # templates by OS version, this is a neat way to do it.  Any Ansible facts, facter facts,
-# or ohai facts could be used to do this.  
+# or ohai facts could be used to do this.
 
 - hosts: all
 

examples/playbooks/tags.yml

@@ -19,7 +19,7 @@
   # the tag to all tasks in it.  Here, each task is given
   # the tag extra
 
-  tags: 
+  tags:
      - extra
 
   tasks:
@@ -36,7 +36,7 @@
   user: root
   tasks:
   - name: hi
-    tags: 
+    tags:
        - bar
     action: shell echo "second task ran"
   - include: tasks/base.yml tags=base

examples/playbooks/tasks/base.yml

@@ -2,7 +2,7 @@
 
 # this is the example of an included tasks file.  It contains a flat list of tasks
 # they can notify other tasks, and have full access to variables from 'vars'
-# or 'vars_files' directives.  Further, if ohai or facter were installed on 
+# or 'vars_files' directives.  Further, if ohai or facter were installed on
 # the remote machines, variables from those tools can be accessed on the 'action'
 # line or in templates.  Just prefix with 'facter_' or 'ohai_' before the particular
 # variable.