diff --git a/docs/docsite/rst/dev_guide/debugging.rst b/docs/docsite/rst/dev_guide/debugging.rst index 45ff665616d..f670b9166c4 100644 --- a/docs/docsite/rst/dev_guide/debugging.rst +++ b/docs/docsite/rst/dev_guide/debugging.rst @@ -104,7 +104,7 @@ Simple debugging The easiest way to run a debugger in a module, either local or remote, is to use `epdb `_. Add ``import epdb; epdb.serve()`` in the module code on the control node at the desired break point. To connect to the debugger, run ``epdb.connect()``. See the `epdb documentation `_ for how to specify the ``host`` and ``port``. If connecting to a remote node, make sure to use a port that is allowed by any firewall between the control node and the remote node. -This technique should work with any remote debugger, but we do not guarantee any particual remote debugging tool will work. +This technique should work with any remote debugger, but we do not guarantee any particular remote debugging tool will work. The `q `_ library is another very useful debugging tool. diff --git a/docs/docsite/rst/dev_guide/developing_collections.rst b/docs/docsite/rst/dev_guide/developing_collections.rst index dd757e55fef..67b255073b9 100644 --- a/docs/docsite/rst/dev_guide/developing_collections.rst +++ b/docs/docsite/rst/dev_guide/developing_collections.rst @@ -779,7 +779,7 @@ If your collection is part of Ansible, use one of the following three options t * Use the ``antsibull-changelog`` tool. -* If are not using this tool, include the properly formatted ``changelog.yaml`` file into your collection. See the `changlog.yaml format `_ for details. +* If are not using this tool, include the properly formatted ``changelog.yaml`` file into your collection. See the `changelog.yaml format `_ for details. * Add a link to own changelogs or release notes in any format by opening an issue at https://github.com/ansible-community/ansible-build-data/ with the HTML link to that information. diff --git a/docs/docsite/rst/dev_guide/developing_modules_general_windows.rst b/docs/docsite/rst/dev_guide/developing_modules_general_windows.rst index 3dd66c2ed88..186907513f6 100644 --- a/docs/docsite/rst/dev_guide/developing_modules_general_windows.rst +++ b/docs/docsite/rst/dev_guide/developing_modules_general_windows.rst @@ -347,7 +347,7 @@ A combination of these flags help to make a module util interoperable on both The following is a list of module_utils that are packaged with Ansible and a general description of what they do: -- ArgvParser: Utiliy used to convert a list of arguments to an escaped string compliant with the Windows argument parsing rules. +- ArgvParser: Utility used to convert a list of arguments to an escaped string compliant with the Windows argument parsing rules. - CamelConversion: Utility used to convert camelCase strings/lists/dicts to snake_case. - CommandUtil: Utility used to execute a Windows process and return the stdout/stderr and rc as separate objects. - FileUtil: Utility that expands on the ``Get-ChildItem`` and ``Test-Path`` to work with special files like ``C:\pagefile.sys``. @@ -395,7 +395,7 @@ Exposing shared module options PowerShell module utils can easily expose common module options that a module can use when building its argument spec. This allows common features to be stored and maintained in one location and have those features used by multiple -modules with minimal effort. Any new features or bugifxes added to one of these utils are then automatically used by +modules with minimal effort. Any new features or bugfixes added to one of these utils are then automatically used by the various modules that call that util. An example of this would be to have a module util that handles authentication and communication against an API This diff --git a/docs/docsite/rst/dev_guide/platforms/aws_guidelines.rst b/docs/docsite/rst/dev_guide/platforms/aws_guidelines.rst index acce3de4976..47a2f4b17e2 100644 --- a/docs/docsite/rst/dev_guide/platforms/aws_guidelines.rst +++ b/docs/docsite/rst/dev_guide/platforms/aws_guidelines.rst @@ -743,7 +743,7 @@ Some cases where tests should be marked as unsupported: 1) The tests take longer than 10 or 15 minutes to complete 2) The tests create expensive resources 3) The tests create inline policies -4) The tests require the existance of external resources +4) The tests require the existence of external resources 5) The tests manage Account level security policies such as the password policy or AWS Organizations. Where one of these reasons apply you should open a pull request proposing the minimum required policy to the diff --git a/docs/docsite/rst/dev_guide/platforms/ovirt_dev_guide.rst b/docs/docsite/rst/dev_guide/platforms/ovirt_dev_guide.rst index bf461d4044b..2d72fac2915 100644 --- a/docs/docsite/rst/dev_guide/platforms/ovirt_dev_guide.rst +++ b/docs/docsite/rst/dev_guide/platforms/ovirt_dev_guide.rst @@ -125,7 +125,7 @@ entity of the SDK. ) # Create the Ansible module, please always implement the - # feautre called 'check_mode', for 'create', 'update' and + # feature called 'check_mode', for 'create', 'update' and # 'delete' operations it's implemented by default in BaseModule: module = AnsibleModule( argument_spec=argument_spec, diff --git a/docs/docsite/rst/dev_guide/platforms/vmware_rest_guidelines.rst b/docs/docsite/rst/dev_guide/platforms/vmware_rest_guidelines.rst index 17bfd3fdcc3..af7d672958b 100644 --- a/docs/docsite/rst/dev_guide/platforms/vmware_rest_guidelines.rst +++ b/docs/docsite/rst/dev_guide/platforms/vmware_rest_guidelines.rst @@ -17,7 +17,7 @@ The modules of the vmware_rest collection are autogenerated by another tool call If you would like to contribute a change, we would appreciate if you: - submit a Github Pull Request (PR) against the vmware_rest_code_generator project -- but also ensure the generated modules are compliant with our quality criterias. +- but also ensure the generated modules are compliant with our quality criteria. Requirements ============ diff --git a/docs/docsite/rst/dev_guide/testing_integration.rst b/docs/docsite/rst/dev_guide/testing_integration.rst index 0880e5b1347..330786160c0 100644 --- a/docs/docsite/rst/dev_guide/testing_integration.rst +++ b/docs/docsite/rst/dev_guide/testing_integration.rst @@ -206,7 +206,7 @@ The `hacking/aws_config/setup_iam.yml` playbook can be used to setup two groups: integration tests not marked as `unsupported` and are designed to mirror those used by Ansible's CI. - `ansible-integration-unsupported` will have the additional policies applied - necessary to run the integraion tests marked as `unsupported` including tests + necessary to run the integration tests marked as `unsupported` including tests for managing IAM roles, users and groups. Once the groups have been created, you'll need to create a user and make the user a member of these diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.3.rst b/docs/docsite/rst/porting_guides/porting_guide_2.3.rst index e214367a2af..d20d74ece9e 100644 --- a/docs/docsite/rst/porting_guides/porting_guide_2.3.rst +++ b/docs/docsite/rst/porting_guides/porting_guide_2.3.rst @@ -19,8 +19,8 @@ This document is part of a collection on porting. The complete list of porting g Playbook ======== -Restructued async to work with action plugins ---------------------------------------------- +Restructured async to work with action plugins +---------------------------------------------- In Ansible 2.2 (and possibly earlier) the `async:` keyword could not be used in conjunction with the action plugins such as `service`. This limitation has been removed in Ansible 2.3 diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_5.rst b/docs/docsite/rst/roadmap/ROADMAP_2_5.rst index 34d376ce47a..1b878f5e889 100644 --- a/docs/docsite/rst/roadmap/ROADMAP_2_5.rst +++ b/docs/docsite/rst/roadmap/ROADMAP_2_5.rst @@ -52,7 +52,7 @@ Facts Static Loop Keyword ------------------- -- A simpler altenative to ``with_``, ``loop:`` only takes a list +- A simpler alternative to ``with_``, ``loop:`` only takes a list - Remove complexity from loops, lookups are still available to users - Less confusing having a static directive vs a one that is dynamic depending on plugins loaded. diff --git a/docs/docsite/rst/scenario_guides/guide_aci.rst b/docs/docsite/rst/scenario_guides/guide_aci.rst index 5fe4c648a50..0c0b7537ba7 100644 --- a/docs/docsite/rst/scenario_guides/guide_aci.rst +++ b/docs/docsite/rst/scenario_guides/guide_aci.rst @@ -648,7 +648,7 @@ You will find our roadmap, an overview of open ACI issues and pull-requests, and `ACI collection on Ansible Galaxy `_ View the content tab for a complete list of supported ACI modules. :ref:`Developing Cisco ACI modules ` - A walkthough on how to develop new Cisco ACI modules to contribute back. + A walkthrough on how to develop new Cisco ACI modules to contribute back. `ACI community `_ The Ansible ACI community wiki page, includes roadmap, ideas and development documentation. :ref:`network_guide` diff --git a/docs/docsite/rst/scenario_guides/guide_azure.rst b/docs/docsite/rst/scenario_guides/guide_azure.rst index 2317ade4a35..ead9b8288c1 100644 --- a/docs/docsite/rst/scenario_guides/guide_azure.rst +++ b/docs/docsite/rst/scenario_guides/guide_azure.rst @@ -132,7 +132,7 @@ Or, pass the following parameters for Active Directory username/password: * password * subscription_id -Or, pass the following parameters for ADFS username/pasword: +Or, pass the following parameters for ADFS username/password: * ad_user * password diff --git a/docs/docsite/rst/user_guide/complex_data_manipulation.rst b/docs/docsite/rst/user_guide/complex_data_manipulation.rst index 5aa230adaeb..6ea3021fee5 100644 --- a/docs/docsite/rst/user_guide/complex_data_manipulation.rst +++ b/docs/docsite/rst/user_guide/complex_data_manipulation.rst @@ -126,7 +126,7 @@ Another way is to avoid adding elements to the list in the first place, so you c :caption: Using set_fact in a loop to increment a list conditionally :emphasize-lines: 3, 4, 6 - - name: build unique list with some items conditionally omittted + - name: build unique list with some items conditionally omitted set_fact: namestuff: ' {{ (namestuff | default([])) | union([item]) }}' when: item != omit @@ -136,7 +136,7 @@ Another way is to avoid adding elements to the list in the first place, so you c - "bar" -.. _complex_type_transfomations: +.. _complex_type_transformations: Complex Type transformations ============================= diff --git a/docs/docsite/rst/user_guide/intro_patterns.rst b/docs/docsite/rst/user_guide/intro_patterns.rst index edc25ad607f..79f199c844c 100644 --- a/docs/docsite/rst/user_guide/intro_patterns.rst +++ b/docs/docsite/rst/user_guide/intro_patterns.rst @@ -153,7 +153,7 @@ Finally, you can use ``--limit`` to read the list of hosts from a file by prefix ansible-playbook site.yml --limit @retry_hosts.txt -If :ref:`RETRY_FILES_ENABLED` is set to ``True``, a ``.retry`` file will be created after the ``ansible-playbook`` run containing a list of failed hosts from all plays. This file is overwritten each time ``ansible-playook`` finishes running. +If :ref:`RETRY_FILES_ENABLED` is set to ``True``, a ``.retry`` file will be created after the ``ansible-playbook`` run containing a list of failed hosts from all plays. This file is overwritten each time ``ansible-playbook`` finishes running. ansible-playbook site.yml --limit @site.retry diff --git a/docs/docsite/rst/user_guide/playbooks_filters.rst b/docs/docsite/rst/user_guide/playbooks_filters.rst index 3af6dc0ecb3..7d200a3a009 100644 --- a/docs/docsite/rst/user_guide/playbooks_filters.rst +++ b/docs/docsite/rst/user_guide/playbooks_filters.rst @@ -318,7 +318,7 @@ List data (before applying the ``zip`` filter):: - apple - orange -Dictonary data (after applying the ``zip`` filter):: +Dictionary data (after applying the ``zip`` filter):: one: apple two: orange diff --git a/test/integration/targets/lookup_fileglob/find_levels/play.yml b/test/integration/targets/lookup_fileglob/find_levels/play.yml index 4bdee05de38..578d482e8e6 100644 --- a/test/integration/targets/lookup_fileglob/find_levels/play.yml +++ b/test/integration/targets/lookup_fileglob/find_levels/play.yml @@ -2,7 +2,7 @@ gather_facts: false vars: expected: - play_adj: ajectent to play + play_adj: adjacent to play play_adj_subdir: in files subdir adjacent to play somepath/play_adj_subsubdir: in play adjacent subdir of files/ in_role: file in role diff --git a/test/integration/targets/lookup_fileglob/find_levels/play_adj.txt b/test/integration/targets/lookup_fileglob/find_levels/play_adj.txt index 14f0cf502bc..2cc44111c67 100644 --- a/test/integration/targets/lookup_fileglob/find_levels/play_adj.txt +++ b/test/integration/targets/lookup_fileglob/find_levels/play_adj.txt @@ -1 +1 @@ -ajectent to play +adjacent to play