Documentation typo fixes (#32473)

docs/docsite/rst/guide_cloudstack.rst

@@ -165,7 +165,7 @@ Below you see an example how it can be used in combination with Ansible's block
 
 .. Note:: You are still able overwrite the environment variables using the module arguments, e.g. ``zone: sf-2``
 
-.. Note:: Unlike ``CLOUDSTACK_REGION`` these additional environment variables are ingored in the CLI ``cs``.
+.. Note:: Unlike ``CLOUDSTACK_REGION`` these additional environment variables are ignored in the CLI ``cs``.
 
 Use Cases
 `````````
@@ -262,7 +262,7 @@ Now to the fun part. We create a playbook to create our infrastructure we call i
           cs_staticnat: vm="{{ inventory_hostname_short }}" ip_address="{{ public_ip }}"
           when: public_ip is defined
 
-In the above play we defined 3 tasks and use the group ``cloud-vm`` as target to handle all VMs in the cloud but instead SSH to these VMs, we use ``connetion=local`` to execute the API calls locally from our workstation.
+In the above play we defined 3 tasks and use the group ``cloud-vm`` as target to handle all VMs in the cloud but instead SSH to these VMs, we use ``connection=local`` to execute the API calls locally from our workstation.
 
 In the first task, we ensure we have a running VM created with the Debian template. If the VM is already created but stopped, it would just start it. If you like to change the offering on an existing VM, you must add ``force: yes`` to the task, which would stop the VM, change the offering and start the VM again.
 
@@ -364,12 +364,12 @@ The playbook looks like the following:
       - name: show VM IP
         debug: msg="VM {{ inventory_hostname }} {{ vm.default_ip }}"
 
-      - name: assing IP to the inventory
+      - name: assign IP to the inventory
         set_fact: ansible_ssh_host={{ vm.default_ip }}
 
       - name: waiting for SSH to come up
         wait_for: port=22 host={{ vm.default_ip }} delay=5
 
-In the first play we setup the security groups, in the second play the VMs will created be assigned to these groups. Further you see, that we assign the public IP returned from the modules to the host inventory. This is needed as we do not know the IPs we will get in advance. In a next step you would configure the DNS servers with these IPs for accassing the VMs with their DNS name.
+In the first play we setup the security groups, in the second play the VMs will created be assigned to these groups. Further you see, that we assign the public IP returned from the modules to the host inventory. This is needed as we do not know the IPs we will get in advance. In a next step you would configure the DNS servers with these IPs for accessing the VMs with their DNS name.
 
 In the last task we wait for SSH to be accessible, so any later play would be able to access the VM by SSH without failure.

docs/docsite/rst/guide_docker.rst

@@ -205,7 +205,7 @@ options. These are the same environment variables used by the Docker modules.
         by docker-py.
 
     DOCKER_TIMEOUT:
-        The maximum amount of time in seconds to wait on a response fromm the API. Defaults to 60 seconds.
+        The maximum amount of time in seconds to wait on a response from the API. Defaults to 60 seconds.
 
     DOCKER_TLS:
         Secure the connection to the API by using TLS without verifying the authenticity of the Docker host server.

docs/docsite/rst/guide_rolling_upgrade.rst

@@ -176,7 +176,7 @@ Here's another example, from the same template:
    {% endfor %}
 
 This loops over all of the hosts in the group called ``monitoring``, and adds an ACCEPT line for 
-each monitoring hosts' default IPV4 address to the current machine's iptables configuration, so that Nagios can monitor those hosts.
+each monitoring hosts' default IPv4 address to the current machine's iptables configuration, so that Nagios can monitor those hosts.
 
 You can learn a lot more about Jinja2 and its capabilities `here <http://jinja.pocoo.org/docs/>`_, and you 
 can read more about Ansible variables in general in the :doc:`playbooks_variables` section.

docs/docsite/rst/playbooks_reuse_roles.rst

@@ -198,7 +198,7 @@ To make roles run more than once, there are two options:
 1. Pass different parameters in each role definition.
 2. Add ``allow_duplicates: true`` to the ``meta/main.yml`` file for the role.
 
-Example 1 - passing different paramters::
+Example 1 - passing different parameters::
 
     ---
     - hosts: webservers