Show more whitespace throughout playbook examples to encourage better standards in first playbooks folks write.

8 files changed, 53 insertions, 6 deletions

diff --git a/docsite/rst/playbooks_acceleration.rst b/docsite/rst/playbooks_acceleration.rst
index e9584ef3d2..c11961ca9d 100644
--- a/docsite/rst/playbooks_acceleration.rst
+++ b/docsite/rst/playbooks_acceleration.rst
@@ -44,9 +44,12 @@ Accelerated mode offers several improvements over the (deprecated) original fire
 In order to use accelerated mode, simply add `accelerate: true` to your play::
 
     ---
+
     - hosts: all
       accelerate: true
+
       tasks:
+
       - name: some task
         command: echo {{ item }}
         with_items:
@@ -57,6 +60,7 @@ In order to use accelerated mode, simply add `accelerate: true` to your play::
 If you wish to change the port Ansible will use for the accelerated connection, just add the `accelerated_port` option::
 
     ---
+
     - hosts: all
       accelerate: true
       # default port is 5099
diff --git a/docsite/rst/playbooks_async.rst b/docsite/rst/playbooks_async.rst
index d94a6986ba..5a82189b65 100644
--- a/docsite/rst/playbooks_async.rst
+++ b/docsite/rst/playbooks_async.rst
@@ -16,9 +16,12 @@ and how frequently you would like to poll for status.  The default
 poll value is 10 seconds if you do not specify a value for `poll`::
 
     ---
+
     - hosts: all
       remote_user: root
+
       tasks:
+
       - name: simulate long running op (15 sec), wait for up to 45, poll every 5
         command: /bin/sleep 15
         async: 45
@@ -33,9 +36,12 @@ Alternatively, if you do not need to wait on the task to complete, you may
 "fire and forget" by specifying a poll value of 0::
 
     ---
+
     - hosts: all
       remote_user: root
+
       tasks:
+
       - name: simulate long running op, allow to run for 45, fire and forget
         command: /bin/sleep 15
         async: 45
diff --git a/docsite/rst/playbooks_best_practices.rst b/docsite/rst/playbooks_best_practices.rst
index 8a2a0e8c15..fbe34ca344 100644
--- a/docsite/rst/playbooks_best_practices.rst
+++ b/docsite/rst/playbooks_best_practices.rst
@@ -305,6 +305,7 @@ This makes a dynamic group of hosts matching certain criteria, even if that grou
    # talk to all hosts just so we can learn about them 
 
    - hosts: all
+
      tasks:
         - group_by: key={{ ansible_distribution }}
 
@@ -312,6 +313,7 @@ This makes a dynamic group of hosts matching certain criteria, even if that grou
 
    - hosts: CentOS
      gather_facts: False
+
      tasks:
         - # tasks that only happen on CentOS go here
 
diff --git a/docsite/rst/playbooks_delegation.rst b/docsite/rst/playbooks_delegation.rst
index 535d2e97bb..0027f4a10a 100644
--- a/docsite/rst/playbooks_delegation.rst
+++ b/docsite/rst/playbooks_delegation.rst
@@ -71,10 +71,12 @@ outage windows.  Using this with the 'serial' keyword to control the number of h
 a good idea::
 
     ---
+
     - hosts: webservers
       serial: 5
 
       tasks:
+
       - name: take out of load balancer pool
         command: /usr/bin/take_out_of_pool {{ inventory_hostname }}
         delegate_to: 127.0.0.1
@@ -87,13 +89,14 @@ a good idea::
         delegate_to: 127.0.0.1
 
 
-These commands will run on 127.0.0.1, which is the machine running Ansible. There is also a shorthand syntax that
-you can use on a per-task basis: 'local_action'. Here is the same playbook as above, but using the shorthand
-syntax for delegating to 127.0.0.1::
+These commands will run on 127.0.0.1, which is the machine running Ansible. There is also a shorthand syntax that you can use on a per-task basis: 'local_action'. Here is the same playbook as above, but using the shorthand syntax for delegating to 127.0.0.1::
 
     ---
+
     # ...
+
       tasks:
+
       - name: take out of load balancer pool
         local_action: command /usr/bin/take_out_of_pool {{ inventory_hostname }}
 
@@ -108,6 +111,7 @@ Here is an example::
     ---
     # ...
       tasks:
+
       - name: recursively copy files from management server to target
         local_action: command rsync -a /path/to/files {{ inventory_hostname }}:/path/to/target/
 
diff --git a/docsite/rst/playbooks_lookups.rst b/docsite/rst/playbooks_lookups.rst
index 0c7822ece0..afa1282154 100644
--- a/docsite/rst/playbooks_lookups.rst
+++ b/docsite/rst/playbooks_lookups.rst
@@ -21,7 +21,9 @@ Contents can be read off the filesystem as follows::
     - hosts: all
       vars:
          contents: "{{ lookup('file', '/etc/foo.txt') }}"
+
       tasks:
+
          - debug: msg="the value of foo.txt is {{ contents }}"
 
 .. _password_lookup:
@@ -128,6 +130,7 @@ template)::
       motd_value: "{{ lookup('file', '/etc/motd') }}"
 
     tasks:
+
       - debug: msg="motd value is {{ motd_value }}"
 
 .. seealso::
diff --git a/docsite/rst/playbooks_prompts.rst b/docsite/rst/playbooks_prompts.rst
index 4b27722f3e..c20e59e079 100644
--- a/docsite/rst/playbooks_prompts.rst
+++ b/docsite/rst/playbooks_prompts.rst
@@ -15,8 +15,10 @@ Here is a most basic example::
     ---
     - hosts: all
       remote_user: root
+
       vars:
         from: "camelot"
+
       vars_prompt:
         name: "what is your name?"
         quest: "what is your quest?"
@@ -27,6 +29,7 @@ provide a default value that can be overridden.  This can be accomplished using
 the default argument::
 
    vars_prompt:
+
      - name: "release_version"
        prompt: "Product release version"
        default: "1.0"
@@ -35,9 +38,11 @@ An alternative form of vars_prompt allows for hiding input from the user, and ma
 some other options, but otherwise works equivalently::
 
    vars_prompt:
+
      - name: "some_password"
        prompt: "Enter password"
        private: yes
+
      - name: "release_version"
        prompt: "Product release version"
        private: no
@@ -46,6 +51,7 @@ If `Passlib <http://pythonhosted.org/passlib/>`_ is installed, vars_prompt can a
 entered value so you can use it, for instance, with the user module to define a password::
 
    vars_prompt:
+
      - name: "my_password2"
        prompt: "Enter password2"
        private: yes
diff --git a/docsite/rst/playbooks_roles.rst b/docsite/rst/playbooks_roles.rst
index d01efe760f..9b9a3b354e 100644
--- a/docsite/rst/playbooks_roles.rst
+++ b/docsite/rst/playbooks_roles.rst
@@ -42,15 +42,18 @@ A task include file simply contains a flat list of tasks, like so::
 
     ---
     # possibly saved as tasks/foo.yml
+
     - name: placeholder foo
       command: /bin/foo
+
     - name: placeholder bar
       command: /bin/bar
 
 Include directives look like this, and can be mixed in with regular tasks in a playbook::
 
    tasks:
-    - include: tasks/foo.yml
+
+     - include: tasks/foo.yml
 
 You can also pass variables into includes.  We call this a 'parameterized include'.
 
@@ -120,7 +123,9 @@ For example::
     - name: this is a play at the top level of a file
       hosts: all
       remote_user: root
+
       tasks:
+
       - name: say hi
         tags: foo
         shell: echo "hi..."
@@ -211,6 +216,7 @@ the roles are evaluated first.
 Also, should you wish to parameterize roles, by adding variables, you can do so, like this::
 
     ---
+
     - hosts: webservers
       roles:
         - common
@@ -220,6 +226,7 @@ Also, should you wish to parameterize roles, by adding variables, you can do so,
 While it's probably not something you should do often, you can also conditionally apply roles like so::
 
     ---
+
     - hosts: webservers
       roles:
         - { role: some_role, when: "ansible_os_family == 'RedHat'" }
@@ -230,6 +237,7 @@ the documentation.
 Finally, you may wish to assign tags to the roles you specify. You can do so inline:::
 
     ---
+
     - hosts: webservers
       roles:
         - { role: foo, tags: ["bar", "baz"] }
@@ -240,13 +248,18 @@ If the play still has a 'tasks' section, those tasks are executed after roles ar
 If you want to define certain tasks to happen before AND after roles are applied, you can do this::
 
     ---
+
     - hosts: webservers
+
       pre_tasks:
         - shell: echo 'hello'
+
       roles:
         - { role: some_role }
+
       tasks:
         - shell: echo 'still busy'
+
       post_tasks:
         - shell: echo 'goodbye'
 
diff --git a/docsite/rst/playbooks_variables.rst b/docsite/rst/playbooks_variables.rst
index 6ae65dcef2..09daac303b 100644
--- a/docsite/rst/playbooks_variables.rst
+++ b/docsite/rst/playbooks_variables.rst
@@ -136,6 +136,7 @@ Filters Often Used With Conditionals
 The following tasks are illustrative of how filters can be used with conditionals::
 
     tasks:
+
       - shell: /usr/bin/foo
         register: result
         ignore_errors: True
@@ -691,13 +692,16 @@ the main playbook.
 You can do this by using an external variables file, or files, just like this::
 
     ---
+
     - hosts: all
       remote_user: root
       vars:
         favcolor: blue
       vars_files:
         - /vars/external_vars.yml
+
       tasks:
+
       - name: this is just a placeholder
         command: /bin/echo foo
 
@@ -731,8 +735,10 @@ This is useful, for, among other things, setting the hosts group or the user for
 Example::
 
     ---
-    - remote_user: '{{ user }}'
-      hosts: '{{ hosts }}'
+
+    - hosts: '{{ hosts }}'
+      remote_user: '{{ user }}'
+
       tasks:
          - ...
 
@@ -765,12 +771,15 @@ As an example, the name of the Apache package may be different between CentOS an
 but it is easily handled with a minimum of syntax in an Ansible Playbook::
 
     ---
+
     - hosts: all
       remote_user: root
       vars_files:
         - "vars/common.yml"
         - [ "vars/{{ ansible_os_family }}.yml", "vars/os_defaults.yml" ]
+
       tasks:
+
       - name: make sure apache is running
         service: name={{ apache }} state=running