ansible · samccann · Sep 26, 2019 · Sep 26, 2019
diff --git a/docs/docsite/rst/dev_guide/developing_modules_general_aci.rst b/docs/docsite/rst/dev_guide/developing_modules_general_aci.rst
@@ -325,7 +325,7 @@ You can test your ``construct_url()`` and ``payload()`` arguments without access
     import json
     from ansible.module_utils.network.aci.aci import ACIModule
 
-    # Just another class mimicking a bare AnsibleModule class for construct_url() and payload() methods
+    # Just another class mimicing a bare AnsibleModule class for construct_url() and payload() methods
     class AltModule():
         params = dict(
             host='dummy',

diff --git a/docs/docsite/rst/dev_guide/developing_plugins.rst b/docs/docsite/rst/dev_guide/developing_plugins.rst
@@ -320,7 +320,7 @@ Lookup plugins pull in data from external data stores. Lookup plugins can be use
 
 Lookup plugins are very flexible, allowing you to retrieve and return any type of data. When writing lookup plugins, always return data of a consistent type that can be easily consumed in a playbook. Avoid parameters that change the returned data type. If there is a need to return a single value sometimes and a complex dictionary other times, write two different lookup plugins.
 
-Ansible includes many :ref:`filters <playbooks_filters>` which can be used to manipulate the data returned by a lookup plugin. Sometimes it makes sense to do the filtering inside the lookup plugin, other times it is better to return results that can be filtered in the playbook. Keep in mind how the data will be referenced when determing the appropriate level of filtering to be done inside the lookup plugin.
+Ansible includes many :ref:`filters <playbooks_filters>` which can be used to manipulate the data returned by a lookup plugin. Sometimes it makes sense to do the filtering inside the lookup plugin, other times it is better to return results that can be filtered in the playbook. Keep in mind how the data will be referenced when determining the appropriate level of filtering to be done inside the lookup plugin.
 
 Here's a simple lookup plugin implementation --- this lookup returns the contents of a text file as a variable:
 

diff --git a/docs/docsite/rst/dev_guide/developing_program_flow_modules.rst b/docs/docsite/rst/dev_guide/developing_program_flow_modules.rst
@@ -620,7 +620,7 @@ no_log
 aliases
 """""""
 
-``aliases`` accepts a list of alternative argument names for the argument, such as the case where the argument is ``name`` but the module accepts ``aliases=['pkg']`` to allow ``pkg`` to be interchangably with ``name``
+``aliases`` accepts a list of alternative argument names for the argument, such as the case where the argument is ``name`` but the module accepts ``aliases=['pkg']`` to allow ``pkg`` to be interchangeably with ``name``
 
 options
 """""""

diff --git a/docs/docsite/rst/dev_guide/platforms/ovirt_dev_guide.rst b/docs/docsite/rst/dev_guide/platforms/ovirt_dev_guide.rst
@@ -44,7 +44,7 @@ Libraries
    along with ``ovirt_full_argument_spec``.
 -  All info modules should use ``extends_documentation_fragment``:
    ``ovirt_info`` to go along with ``ovirt_info_full_argument_spec``.
--  Functions that are common to all modules should be implemeneted in the
+-  Functions that are common to all modules should be implemented in the
    ``module_utils/ovirt.py`` file, so they can be reused.
 -  Python SDK version 4 must be used.
 

diff --git a/docs/docsite/rst/network/user_guide/platform_cnos.rst b/docs/docsite/rst/network/user_guide/platform_cnos.rst
@@ -65,7 +65,7 @@ Example CLI Task
 
 .. code-block:: yaml
 
-   - name: Retreive CNOS OS version
+   - name: Retrieve CNOS OS version
      cnos_command:
        commands: show version
      when: ansible_network_os == 'cnos'

diff --git a/docs/docsite/rst/network/user_guide/platform_enos.rst b/docs/docsite/rst/network/user_guide/platform_enos.rst
@@ -67,7 +67,7 @@ Example CLI Task
 
 .. code-block:: yaml
 
-   - name: Retreive ENOS OS version
+   - name: Retrieve ENOS OS version
      enos_command:
        commands: show version
      when: ansible_network_os == 'enos'

diff --git a/docs/docsite/rst/network/user_guide/platform_index.rst b/docs/docsite/rst/network/user_guide/platform_index.rst
@@ -41,7 +41,7 @@ Settings by Platform
 .. raw:: html
 
     <style>
-    /* Style for this single table.  Add delimiters between header colums */
+    /* Style for this single table.  Add delimiters between header columns */
     table#network-platform-table thead tr th.head {
       border-left-width: 1px;
       border-left-color: rgb(225, 228, 229);

diff --git a/docs/docsite/rst/network/user_guide/platform_nxos.rst b/docs/docsite/rst/network/user_guide/platform_nxos.rst
@@ -137,7 +137,7 @@ Cisco Nexus Platform Support Matrix
 
 The following platforms and software versions have been certified by Cisco to work with this version of Ansible.
 
-.. table:: Platform / Software Mininum Requirements
+.. table:: Platform / Software Minimum Requirements
      :align: center
 
      ===================  =====================

diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.5.rst b/docs/docsite/rst/porting_guides/porting_guide_2.5.rst
@@ -254,7 +254,7 @@ Inventory plugins have been fine tuned, and we have started to add some common f
 Shell
 -----
 
-Shell plugins have been migrated to the new plugin configuration framework. It is now possible to customize more settings, and settings which were previously 'global' can now also be overriden using host specific variables.
+Shell plugins have been migrated to the new plugin configuration framework. It is now possible to customize more settings, and settings which were previously 'global' can now also be overridden using host specific variables.
 
 For example, ``system_temps`` is a new setting that allows you to control what Ansible will consider a 'system temporary dir'. This is used when escalating privileges for a non-administrative user. Previously this was hardcoded to '/tmp', which some systems cannot use for privilege escalation. This setting now defaults to ``[ '/var/tmp', '/tmp']``.
 

diff --git a/docs/docsite/rst/reference_appendices/faq.rst b/docs/docsite/rst/reference_appendices/faq.rst
@@ -651,7 +651,7 @@ but you can still access the original via ``hostvars``::
 
    original_host: "{{ hostvars[inventory_hostname]['ansible_host'] }}"
 
-This works for all overriden connection variables, like ``ansible_user``, ``ansible_port``, etc.
+This works for all overridden connection variables, like ``ansible_user``, ``ansible_port``, etc.
 
 
 .. _scp_protocol_error_filename:

diff --git a/docs/docsite/rst/scenario_guides/guide_aci.rst b/docs/docsite/rst/scenario_guides/guide_aci.rst
@@ -611,7 +611,7 @@ The :ref:`aci_rest <aci_rest_module>` module is a wrapper around the APIC REST A
 All below issues either have been reported to the vendor, and most can simply be avoided.
 
     Too many consecutive API calls may result in connection throttling
-        Starting with ACI v3.1 the APIC will actively throttle password-based authenticated connection rates over a specific treshold. This is as part of an anti-DDOS measure but can act up when using Ansible with ACI using password-based authentication. Currently, one solution is to increase this threshold within the nginx configuration, but using signature-based authentication is recommended.
+        Starting with ACI v3.1 the APIC will actively throttle password-based authenticated connection rates over a specific threshold. This is as part of an anti-DDOS measure but can act up when using Ansible with ACI using password-based authentication. Currently, one solution is to increase this threshold within the nginx configuration, but using signature-based authentication is recommended.
 
         **NOTE:** It is advisable to use signature-based authentication with ACI as it not only prevents connection-throttling, but also improves general performance when using the ACI modules.
 

diff --git a/docs/docsite/rst/scenario_guides/guide_vagrant.rst b/docs/docsite/rst/scenario_guides/guide_vagrant.rst
@@ -136,7 +136,7 @@ Advanced Usages
 The "Tips and Tricks" chapter of the `Ansible Provisioner documentation
 <https://www.vagrantup.com/docs/provisioning/ansible.html>`_ provides detailed information about more advanced Ansible features like:
 
-  - how to parallely execute a playbook in a multi-machine environment
+  - how to execute a playbook in parallel within a multi-machine environment
   - how to integrate a local ``ansible.cfg`` configuration file
 
 .. seealso::

diff --git a/docs/docsite/rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst b/docs/docsite/rst/scenario_guides/vmware_scenarios/scenario_remove_vm.rst
@@ -41,7 +41,7 @@ Caveats
 
 - All variable names and VMware object names are case sensitive.
 - You need to use Python 2.7.9 version in order to use ``validate_certs`` option, as this version is capable of changing the SSL verification behaviours.
-- ``vmware_guest`` module tries to mimick VMware Web UI and workflow, so the virtual machine must be in powered off state in order to remove it from the VMware inventory.
+- ``vmware_guest`` module tries to mimic VMware Web UI and workflow, so the virtual machine must be in powered off state in order to remove it from the VMware inventory.
 
 .. warning::
 

diff --git a/docs/docsite/rst/user_guide/playbooks_best_practices.rst b/docs/docsite/rst/user_guide/playbooks_best_practices.rst
@@ -427,7 +427,7 @@ Alternatively, if only variables are needed::
 
     - hosts: all
       tasks:
-        - name: Set OS distribution dependant variables
+        - name: Set OS distribution dependent variables
           include_vars: "os_{{ ansible_facts['distribution'] }}.yml"
         - debug:
             var: asdf

diff --git a/docs/docsite/rst/user_guide/playbooks_filters.rst b/docs/docsite/rst/user_guide/playbooks_filters.rst
@@ -286,7 +286,7 @@ To always exhaust all list use ``zip_longest``::
         msg: "{{ [1,2,3] | zip_longest(['a','b','c','d','e','f'], [21, 22, 23], fillvalue='X') | list }}"
 
 
-Similarly to the output of the ``items2dict`` filter mentioned above, these filters can be used to contruct a ``dict``::
+Similarly to the output of the ``items2dict`` filter mentioned above, these filters can be used to construct a ``dict``::
 
     {{ dict(keys_list | zip(values_list)) }}
 
@@ -824,7 +824,7 @@ To sort a VLAN list::
 
     {{ [3003, 3004, 3005, 100, 1688, 3002, 3999] | vlan_parser }}
 
-This example renders the folllowing sorted list::
+This example renders the following sorted list::
 
     ['100,1688,3002-3005,3999']
 

diff --git a/docs/docsite/rst/user_guide/windows_dsc.rst b/docs/docsite/rst/user_guide/windows_dsc.rst
@@ -84,7 +84,7 @@ used - in this case the ``resource_name`` should be set to ``Registry``. The
 installed; if left blank it will default to the latest version. The other
 options are parameters that are used to define the resource, such as ``Key`` and
 ``ValueName``. While the options in the task are not case sensitive,
-keeping the case as-is is recommended becuase it makes it easier to distinguish DSC
+keeping the case as-is is recommended because it makes it easier to distinguish DSC
 resource options from Ansible's ``win_dsc`` options.
 
 This is what the Ansible task version of the above DSC Registry resource would look like: