updated documentation fixing #47202 (#47267)

docs/docsite/rst/user_guide/playbooks_async.rst

@@ -62,7 +62,7 @@ following::
       - name: 'YUM - async task'
         yum:
           name: docker-io
-          state: installed
+          state: present
         async: 1000
         poll: 0
         register: yum_sleeper

docs/docsite/rst/user_guide/playbooks_best_practices.rst

@@ -14,12 +14,12 @@ You can find some example playbooks illustrating these best practices in our `an
 Content Organization
 ++++++++++++++++++++++
 
-The following section shows one of many possible ways to organize playbook content. 
+The following section shows one of many possible ways to organize playbook content.
 
 Your usage of Ansible should fit your needs, however, not ours, so feel free to modify this approach and organize as you see fit.
 
 One crucial way to organize your playbook content is Ansible's "roles" organization feature, which is documented as part
-of the main playbooks page.  You should take the time to read and understand the roles documentation which is available here: :doc:`playbooks_reuse_roles`.  
+of the main playbooks page.  You should take the time to read and understand the roles documentation which is available here: :doc:`playbooks_reuse_roles`.
 
 .. _directory_layout:
 
@@ -50,7 +50,7 @@ The top level of the directory would contain files and directories like so::
         common/               # this hierarchy represents a "role"
             tasks/            #
                 main.yml      #  <-- tasks file can include smaller files if warranted
-            handlers/         # 
+            handlers/         #
                 main.yml      #  <-- handlers file
             templates/        #  <-- files for use with the template resource
                 ntp.conf.j2   #  <------- templates end in .j2
@@ -69,7 +69,7 @@ The top level of the directory would contain files and directories like so::
 
         webtier/              # same kind of structure as "common" was above, done for the webtier role
         monitoring/           # ""
-        fooapp/               # "" 
+        fooapp/               # ""
 
 .. note: If you find yourself having too many top level playbooks (for instance you have a playbook you wrote for a specific hotfix, etc), it may make sense to have a playbooks/ directory instead.  This can be a good idea as you get larger.  If you do this, configure your roles_path in ansible.cfg to find your roles location.
 
@@ -120,7 +120,7 @@ This layout gives you more flexibility for larger environments, as well as a tot
 Use Dynamic Inventory With Clouds
 `````````````````````````````````
 
-If you are using a cloud provider, you should not be managing your inventory in a static file.  See :doc:`intro_dynamic_inventory`. 
+If you are using a cloud provider, you should not be managing your inventory in a static file.  See :doc:`intro_dynamic_inventory`.
 
 This does not just apply to clouds -- If you have another system maintaining a canonical list of systems
 in your infrastructure, usage of dynamic inventory is a great idea in general.
@@ -134,7 +134,7 @@ If managing static inventory, it is frequently asked how to differentiate differ
 shows a good way to do this.  Similar methods of grouping could be adapted to dynamic inventory (for instance, consider applying the AWS
 tag "environment:production", and you'll get a group of systems automatically discovered named "ec2_tag_environment_production".
 
-Let's show a static inventory example though.  Below, the *production* file contains the inventory of all of your production hosts. 
+Let's show a static inventory example though.  Below, the *production* file contains the inventory of all of your production hosts.
 
 It is suggested that you define groups based on purpose of the host (roles) and also geography or datacenter location (if applicable)::
 
@@ -201,7 +201,7 @@ If we had any default values, or values that were universally true, we would put
     ---
     # file: group_vars/all
     ntp: ntp-boston.example.com
-    backup: backup-boston.example.com 
+    backup: backup-boston.example.com
 
 We can define specific hardware variance in systems in a host_vars file, but avoid doing this unless you need to::
 
@@ -210,8 +210,8 @@ We can define specific hardware variance in systems in a host_vars file, but avo
     foo_agent_port: 86
     bar_agent_port: 99
 
-Again, if we are using dynamic inventory sources, many dynamic groups are automatically created.  So a tag like "class:webserver" would load in 
-variables from the file "group_vars/ec2_tag_class_webserver" automatically. 
+Again, if we are using dynamic inventory sources, many dynamic groups are automatically created.  So a tag like "class:webserver" would load in
+variables from the file "group_vars/ec2_tag_class_webserver" automatically.
 
 .. _split_by_role:
 
@@ -254,7 +254,7 @@ Below is an example tasks file that explains how a role works.  Our common role
     - name: be sure ntp is installed
       yum:
         name: ntp
-        state: installed
+        state: present
       tags: ntp
 
     - name: be sure ntp is configured
@@ -309,7 +309,7 @@ For just my webservers in Boston::
     ansible-playbook -i production webservers.yml --limit boston
 
 For just the first 10, and then the next 10::
-   
+
     ansible-playbook -i production webservers.yml --limit boston[0:9]
     ansible-playbook -i production webservers.yml --limit boston[10:19]
 
@@ -432,7 +432,7 @@ Alternatively, if only variables are needed::
         - debug:
             var: asdf
 
-This will pull in variables based on the OS name.  
+This will pull in variables based on the OS name.
 
 .. _ship_modules_with_playbooks:
 
@@ -455,7 +455,7 @@ Generous use of whitespace to break things up, and use of comments (which start
 Always Name Tasks
 +++++++++++++++++
 
-It is possible to leave off the 'name' for a given task, though it is recommended to provide a description 
+It is possible to leave off the 'name' for a given task, though it is recommended to provide a description
 about why something is being done instead.  This name is shown when the playbook is run.
 
 .. _keep_it_simple:

docs/docsite/rst/user_guide/playbooks_blocks.rst

@@ -14,7 +14,7 @@ Blocks allow for logical grouping of tasks and in play error handling. Most of w
       - name: install httpd and memcached
         yum:
           name: "{{ item }}"
-          state: installed
+          state: present
         loop:
           - httpd
           - memcached

docs/docsite/rst/user_guide/playbooks_tags.rst

@@ -17,7 +17,7 @@ that tags two tasks with different tags::
     tasks:
         - yum:
             name: "{{ item }}"
-            state: installed
+            state: present
           loop:
              - httpd
              - memcached
@@ -55,7 +55,7 @@ This example tags several tasks with one tag, "ntp"::
     - name: be sure ntp is installed
       yum:
         name: ntp
-        state: installed
+        state: present
       tags: ntp
 
     - name: be sure ntp is configured
@@ -133,7 +133,7 @@ There is no way to 'import only these tags'; you probably want to split into sma
 The above information does not apply to `include_tasks` or other dynamic includes,
 as the attributes applied to an include, only affect the include itself.
 
-You can see which tags are applied to tasks, roles, and static imports 
+You can see which tags are applied to tasks, roles, and static imports
 by running ``ansible-playbook`` with the ``--list-tasks`` option. You can
 display all tags applied to the tasks with the ``--list-tags`` option.
 
@@ -156,7 +156,7 @@ Playbook file::
       tasks:
       - include_role:
           name: myrole
-        tags: mytag  
+        tags: mytag
 
 Role tasks file::