Fix typos (#72072)
This commit is contained in:
parent
1107aace1b
commit
2b79cd2c0f
16 changed files with 19 additions and 19 deletions
|
@ -104,7 +104,7 @@ Simple debugging
|
|||
|
||||
The easiest way to run a debugger in a module, either local or remote, is to use `epdb <https://pypi.org/project/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 <https://pypi.org/project/epdb/>`_ 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 <https://pypi.org/project/q/>`_ library is another very useful debugging tool.
|
||||
|
||||
|
|
|
@ -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 <https://github.com/ansible-community/antsibull-changelog/blob/main/docs/changelog.yaml-format.md>`_ for details.
|
||||
* If are not using this tool, include the properly formatted ``changelog.yaml`` file into your collection. See the `changelog.yaml format <https://github.com/ansible-community/antsibull-changelog/blob/main/docs/changelog.yaml-format.md>`_ 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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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,
|
||||
|
|
|
@ -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
|
||||
============
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -648,7 +648,7 @@ You will find our roadmap, an overview of open ACI issues and pull-requests, and
|
|||
`ACI collection on Ansible Galaxy <https://galaxy.ansible.com/cisco/aci>`_
|
||||
View the content tab for a complete list of supported ACI modules.
|
||||
:ref:`Developing Cisco ACI modules <aci_dev_guide>`
|
||||
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 <https://github.com/ansible/community/wiki/Network:-ACI>`_
|
||||
The Ansible ACI community wiki page, includes roadmap, ideas and development documentation.
|
||||
:ref:`network_guide`
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
=============================
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -1 +1 @@
|
|||
ajectent to play
|
||||
adjacent to play
|
||||
|
|
Loading…
Reference in a new issue