diff --git a/docs/docsite/rst/community/collection_contributors/collection_integration_about.rst b/docs/docsite/rst/community/collection_contributors/collection_integration_about.rst index 652b11f631c..d011fdb0642 100644 --- a/docs/docsite/rst/community/collection_contributors/collection_integration_about.rst +++ b/docs/docsite/rst/community/collection_contributors/collection_integration_about.rst @@ -128,7 +128,7 @@ To check a task: #. Expected return values. 2. If the module changes the system state, check the actual system state using at least one other module. For example, if the module changes a file, we can check that the file has been changed by checking its checksum with the :ref:`stat ` module before and after the test tasks. -3. Run the same task with ``check_mode: yes`` if check-mode is supported by the module. Check with other modules that the actual system state has not been changed. +3. Run the same task with ``check_mode: true`` if check-mode is supported by the module. Check with other modules that the actual system state has not been changed. 4. Cover cases when the module must fail. Use the ``ignore_errors: true`` option and check the returned message with the ``assert`` module. Example: diff --git a/docs/docsite/rst/community/collection_contributors/collection_integration_add.rst b/docs/docsite/rst/community/collection_contributors/collection_integration_add.rst index b73c0326608..ad30b02773a 100644 --- a/docs/docsite/rst/community/collection_contributors/collection_integration_add.rst +++ b/docs/docsite/rst/community/collection_contributors/collection_integration_add.rst @@ -36,7 +36,7 @@ We should basically do the following: 1. Clone the collection to the ``~/ansible_collections/community.abstract`` directory on your local machine. -2. From the ``~/ansble_collections/community.abstract`` directory, create directories for the ``setup`` target: +2. From the ``~/ansible_collections/community.abstract`` directory, create directories for the ``setup`` target: .. code-block:: bash @@ -63,7 +63,7 @@ This is a very simplified example. 4. Add the target for the module you are testing. -Let's say the module is called ``abstact_service_info``. Create the following directory structure in the target: +Let's say the module is called ``abstract_service_info``. Create the following directory structure in the target: .. code-block:: bash @@ -90,7 +90,7 @@ Add the following to ``tests/integration/targets/abstract_service_info/tasks/mai .. code-block:: yaml - name: Fetch info from abstract service - anstract_service_info: + abstract_service_info: host: 127.0.0.1 # We assume the service accepts local connection by default port: 1234 # We assume that the service is listening this port by default register: result # This variable will contain the returned JSON including the server version diff --git a/docs/docsite/rst/community/collection_contributors/collection_release_with_branches.rst b/docs/docsite/rst/community/collection_contributors/collection_release_with_branches.rst index 9cc7054fb94..d48cb24fee9 100644 --- a/docs/docsite/rst/community/collection_contributors/collection_release_with_branches.rst +++ b/docs/docsite/rst/community/collection_contributors/collection_release_with_branches.rst @@ -213,7 +213,7 @@ Publishing the collection Releasing patch versions ------------------------- -The new version is assumed to be ``X.Y.Z``, and the previous patch version is assumed to be ``X.Y.z`` with ``z < Z``. ``z`` is frequently``0`` snce patch releases are uncommon. +The new version is assumed to be ``X.Y.Z``, and the previous patch version is assumed to be ``X.Y.z`` with ``z < Z``. ``z`` is frequently``0`` since patch releases are uncommon. Releasing when more minor versions are expected ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/docs/docsite/rst/community/collection_development_process.rst b/docs/docsite/rst/community/collection_development_process.rst index afe693a265e..2da39649255 100644 --- a/docs/docsite/rst/community/collection_development_process.rst +++ b/docs/docsite/rst/community/collection_development_process.rst @@ -46,6 +46,8 @@ We do not merge every PR. See :ref:`collection_quickstart` for tips to make you Creating changelog fragments ----------------------------- +Most changelogs should emphasize the impact of the change on the end user of the feature or collection, unless the change impacts developers directly. Consider what the user needs to know about this change and write the changelog to convey that detail. + Changelogs help users and developers keep up with changes to Ansible collections. Many collections build changelogs for each release from fragments. For collections that use this model, you **must** add a changelog fragment to any PR that changes functionality or fixes a bug. You do not need a changelog fragment for PRs that: diff --git a/docs/docsite/rst/community/communication.rst b/docs/docsite/rst/community/communication.rst index f6232a748f6..8b224d9f569 100644 --- a/docs/docsite/rst/community/communication.rst +++ b/docs/docsite/rst/community/communication.rst @@ -67,7 +67,7 @@ The Ansible community maintains several IRC channels on `irc.libera.chat `_ - `Git `_ - `GitHub collaborative development model through forks and pull requests `_ -You can learn these tools more in depth when working on your first contributions. +You can learn these tools more in-depth when working on your first contributions. -Each Ansible project has its own set of contributor guidelines. Familarize yourself with these as you prepare your first contributions. +Each Ansible project has its own set of contributor guidelines. Familiarize yourself with these as you prepare your first contributions. * :ref:`Ansible Core development `. * :ref:`Ansible collection development ` and the collection-level contributor guidelines in the collection repository. @@ -72,18 +72,18 @@ See :ref:`communication` for ways to communicate and engage with the Ansible com Teach others ============ -Share your experience with other contributors through `improving documentation `, answering question from other contributors and users on `Matrix/Libera.Chat IRC `, giving advice in issues and pull requests, and discussing the `Community Topics `_. +Share your experience with other contributors through :ref:`improving documentation`, and answering questions from other contributors and users on :ref:`Matrix/Libera.Chat IRC`, giving advice on issues and pull requests, and discussing `Community Topics `_. Become a collection maintainer =============================== If you are a code contributor to a collection, you can get extended permissions in the repository and become a maintainer. A collection maintainer is a contributor trusted by the community who makes significant and regular contributions to the project and showed themselves as a specialist in the related area. See :ref:`maintainers` for details. -For some collections that use the `collection bot `_ , such as `community.general `_ and `community.network `_, you can have different levels of access and permissions. +For some collections that use the `collection bot `_, such as `community.general `_ and `community.network `_, you can have different levels of access and permissions. * `module_maintainers` - The stage prior to becoming a collection maintainer. The file is usually a module or plugin. File maintainers have indirect commit rights. * supershipit permissions - Similar to being a file maintainer but the scope where a maintainer has the indirect commit is the whole repository. -* ``triage`` - Access to the repository that allows contributors manage issues and pull requests. +* ``triage`` - Access to the repository that allows contributors to manage issues and pull requests. * ``write`` access to the repository also known as ``commit``. In other words, become a committer. This access level allows contributors to merge pull requests to the development branch as well as perform all the other activities listed in the :ref:`maintainers`. For information about permission levels, see the `GitHub official documentation `_. @@ -95,7 +95,7 @@ Become a steering committee member You do NOT have to be a programmer to become a steering committee member. -The :ref:`Steering Committee ` member status reflects the highest level of trust which allows contributors to lead the project through making very important `decisions `_ for the Ansible project. The Committee members are the community leaders who shape the project's future and the future of automation in the IT world in general. +The :ref:`Steering Committee ` member status reflects the highest level of trust which allows contributors to lead the project by making very important `decisions `_ for the Ansible project. The Committee members are the community leaders who shape the project's future and the future of automation in the IT world in general. To reach the status, as the current Committee members did before getting it, along with the things mentioned in this document, you should: diff --git a/docs/docsite/rst/community/create_pr_quick_start.rst b/docs/docsite/rst/community/create_pr_quick_start.rst index d06f58ddd7d..083a1f2b7e3 100644 --- a/docs/docsite/rst/community/create_pr_quick_start.rst +++ b/docs/docsite/rst/community/create_pr_quick_start.rst @@ -92,7 +92,7 @@ Change the code .. note:: - Do NOT mix several bugfixes or features that are not tightly-related in one pull request. Use separate pull requests for different changes. + Do NOT mix several bug fixes or features that are not tightly related in one pull request. Use separate pull requests for different changes. You should start with writing integration and unit tests if applicable. These can verify the bug exists (prior to your code fix) and verify your code fixed that bug once the tests pass. @@ -113,7 +113,7 @@ The ``main.yml`` file holds test tasks and includes other test files. Look for a suitable test file to integrate your tests or create and include a dedicated test file. You can use one of the existing test files as a draft. -When fixing a bug, write a task which reproduces the bug from the issue. +When fixing a bug, write a task that reproduces the bug from the issue. Put the reported case in the tests, then run integration tests with the following command: @@ -121,16 +121,16 @@ Put the reported case in the tests, then run integration tests with the followin $ ansible-test integration name_of_test_subdirectory --docker -v -For example, if the tests files you changed are stored in ``tests/integration/targets/test_mysql_user/``, the command is as follows: +For example, if the test files you changed are stored in ``tests/integration/targets/test_mysql_user/``, the command is as follows: .. code-block:: bash $ ansible-test integration test_mysql_user --docker -v -You can use the ``-vv`` or ``-vvv`` argument, if you need more detailed output. +You can use the ``-vv`` or ``-vvv`` argument if you need more detailed output. In the examples above, the default test image is automatically downloaded and used to create and run a test container. -Use the default test image for platform independent integration tests such as those for cloud modules. +Use the default test image for platform-independent integration tests such as those for cloud modules. If you need to run the tests against a specific distribution, see the :ref:`list of supported container images `. For example: @@ -145,7 +145,7 @@ If you need to run the tests against a specific distribution, see the :ref:`list If the tests ran successfully, there are usually two possible outcomes: - If the bug has not appeared and the tests have passed successfully, ask the reporter to provide more details. It may not be a bug or can relate to a particular software version used or specifics of the reporter's local environment configuration. -- The bug has appeared and the tests has failed as expected showing the reported symptoms. +- The bug has appeared and the tests have failed as expected showing the reported symptoms. Fix the bug ============= @@ -155,6 +155,8 @@ See :ref:`module_contribution` for some general guidelines about Ansible module Test your changes ================= + If using the ``docker`` CLI program, the host must be configured to use cgroupsv1 (this is not required for ``podman``). This can be done by adding ``systemd.unified_cgroup_hierarchy=0`` to the kernel boot arguments (requires bootloader config update and reboot). + 1. Install ``flake8`` (``pip install flake8``, or install the corresponding package on your operating system). 1. Run ``flake8`` against a changed file: @@ -164,7 +166,7 @@ Test your changes $ flake8 path/to/changed_file.py - This shows unused imports, which is not shown by sanity tests, as well as other common issues. + This shows unused imports, which are not shown by sanity tests, as well as other common issues. Optionally, you can use the ``--max-line-length=160`` command-line argument. 2. Run sanity tests: @@ -193,7 +195,7 @@ Test your changes There are two possible outcomes: -- They have failed. Look at the output of the command. Fix the problem place in the code and run again. Repeat the cycle until the tests pass. +- They have failed. Look at the output of the command. Fix the problem in the code and run again. Repeat the cycle until the tests pass. - They have passed. Remember they failed originally? Our congratulations! You have fixed the bug. In addition to the integration tests, you can also cover your changes with unit tests. This is often required when integration tests are not applicable to the collection. @@ -234,7 +236,7 @@ Submit a pull request GitHub is tracking your fork, so it should see the new branch in it and automatically offer to create a pull request. Sometimes GitHub does not do it, and you should click the :guilabel:`New pull request` button yourself. Then choose :guilabel:`compare across forks` under the :guilabel:`Compare changes` title. -5.Choose your repository and the new branch you pushed in the right drop-down list. Confirm. +5. Choose your repository and the new branch you pushed in the right drop-down list. Confirm. a. Fill out the pull request template with all information you want to mention. @@ -263,9 +265,9 @@ Submit a pull request 7. Verify the CI tests pass that run automatically on Red Hat infrastructure after every commit. - You will see the CI status in the bottom of your pull request. If they are green and you think that you do not want to add more commits before someone should take a closer look at it, remove ``[WIP]`` from the title. Mention the issue reporter in a comment and let contributors know that the pull request is "Ready for review". + You will see the CI status at the bottom of your pull request. If they are green and you think that you do not want to add more commits before someone should take a closer look at it, remove ``[WIP]`` from the title. Mention the issue reporter in a comment and let contributors know that the pull request is "Ready for review". -8. Wait for reviews. You can also ask for review in the ``#ansible-community`` :ref:`Matrix/Libera.Chat IRC channel `. +8. Wait for reviews. You can also ask for a review in the ``#ansible-community`` :ref:`Matrix/Libera.Chat IRC channel `. 9. If the pull request looks good to the community, committers will merge it. diff --git a/docs/docsite/rst/community/how_can_I_help.rst b/docs/docsite/rst/community/how_can_I_help.rst index ceeea05f467..66f55d1898c 100644 --- a/docs/docsite/rst/community/how_can_I_help.rst +++ b/docs/docsite/rst/community/how_can_I_help.rst @@ -61,7 +61,7 @@ Review and submit pull requests As you become more familiar with how Ansible works, you may be able to fix issues or develop new features yourself. If you think you have a fix for a bug in Ansible, or if you have a new feature that you would like to share with millions of Ansible users, read all about the :ref:`development process ` to learn how to get your code accepted into Ansible. -Another good way to help is to review pull requests that other Ansible users have submitted. Ansible core keeps a full list of `open pull requests by file `_, so if a particular module or plugin interests you, you can easily keep track of all the relevant new pull requests and provide testing or feedback. Alternately, you can review the pull requests for any collections that interest you. Click :guilabel:`Issue tracker` on the collection documentation page to find the issues and PRs for that collection. +Another good way to help is to review pull requests that other Ansible users have submitted. Ansible core keeps a full list of `open pull requests by file `_, so if a particular module or plugin interests you, you can easily keep track of all the relevant new pull requests and provide testing or feedback. Alternatively, you can review the pull requests for any collections that interest you. Click :guilabel:`Issue tracker` on the collection documentation page to find the issues and PRs for that collection. Become a collection maintainer ============================== diff --git a/docs/docsite/rst/community/index.rst b/docs/docsite/rst/community/index.rst index e8ae75708bf..b5ddb51d659 100644 --- a/docs/docsite/rst/community/index.rst +++ b/docs/docsite/rst/community/index.rst @@ -12,7 +12,7 @@ Ansible Community Guide Welcome to the Ansible Community Guide! -The purpose of this guide is to teach you everything you need to know about being a contributing member of the Ansible community. All types of contributions are welcome and necessary to Ansible's continued success. +The purpose of this guide is to teach you everything you need to know about being a contributing member of the Ansible community. All types of contributions are welcome and necessary for Ansible's continued success. .. _community_toc: diff --git a/docs/docsite/rst/community/reporting_collections.rst b/docs/docsite/rst/community/reporting_collections.rst index 806ce6e4cb0..1d8c2e60f9f 100644 --- a/docs/docsite/rst/community/reporting_collections.rst +++ b/docs/docsite/rst/community/reporting_collections.rst @@ -31,6 +31,6 @@ Requesting a feature ==================== Before you request a feature, check what is :ref:`planned for future Ansible Releases `. -The best way to get a feature into an Ansible collection is to :ref:`submit a pull request `, either against ansible-core or against a collection. See also :ref:`ansible_collection_merge_requirements`. +The best way to get a feature into an Ansible collection is to :ref:`submit a pull request `, either against ansible-core or against a collection. See also the :ref:`ansible_collection_merge_requirements`. -You can also submit a feature request through opening an issue in the collection repository. +You can also submit a feature request by opening an issue in the collection repository. diff --git a/docs/docsite/rst/dev_guide/developing_collections_structure.rst b/docs/docsite/rst/dev_guide/developing_collections_structure.rst index 997b0ad0146..77d4e8bf56d 100644 --- a/docs/docsite/rst/dev_guide/developing_collections_structure.rst +++ b/docs/docsite/rst/dev_guide/developing_collections_structure.rst @@ -189,10 +189,10 @@ You can have most of the subdirectories you would expect, such ``files/``, ``var Also, playbooks within a collection follow the same guidelines as any playbooks except for these few adjustments: - - Directory: It must be in ``/playbooks directory``. + - Directory: It must be in the ``playbooks/`` directory. - Hosts: The host should be defined as a variable so the users of a playbook do not mistakenly run the plays against their entire inventory (if the host is set to all). For example - ``hosts: '{{target|default("all")}}'``. -To run the plays, users can now use such commands as ``ansible-playbook --e 'targets=webservers'`` or ``ansible-playbook --limit webservers``. Either way, the collection owner should document their playbooks and how to use them in the ``/docs`` folder or ``README`` file. +To run the plays, users can now use such commands as ``ansible-playbook --e 'targets=webservers'`` or ``ansible-playbook --limit webservers``. Either way, the collection owner should document their playbooks and how to use them in the ``docs/`` folder or ``README`` file. .. _developing_collections_tests_directory: diff --git a/docs/docsite/rst/dev_guide/developing_python_3.rst b/docs/docsite/rst/dev_guide/developing_python_3.rst index a58ee1ae35e..74385c43f9d 100644 --- a/docs/docsite/rst/dev_guide/developing_python_3.rst +++ b/docs/docsite/rst/dev_guide/developing_python_3.rst @@ -89,7 +89,7 @@ and while Python 2 is not a concern anymore we will continue to use them as they dealing with unicode problematic. While we will not be using it most of it anymore, the documentation below is still useful for those developing modules -that still need to support both Python 2 and 3 simultaneouslly. +that still need to support both Python 2 and 3 simultaneously. Unicode Sandwich common borders: places to convert bytes to text in controller code ----------------------------------------------------------------------------------- diff --git a/docs/docsite/rst/dev_guide/overview_architecture.rst b/docs/docsite/rst/dev_guide/overview_architecture.rst index 2a3fe55bab9..89677e96d9a 100644 --- a/docs/docsite/rst/dev_guide/overview_architecture.rst +++ b/docs/docsite/rst/dev_guide/overview_architecture.rst @@ -53,7 +53,7 @@ Here's what a plain text inventory file looks like: db0.example.com db1.example.com -Once inventory hosts are listed, variables can be assigned to them in simple text files (in a subdirectory called 'group_vars/' or 'host_vars/' or directly in the inventory file. +Once inventory hosts are listed, variables can be assigned to them in simple text files (in a subdirectory called 'group_vars/' or 'host_vars/') or directly in the inventory file. Or, as already mentioned, use a dynamic inventory to pull your inventory from data sources like EC2, Rackspace, or OpenStack. diff --git a/docs/docsite/rst/inventory/implicit_localhost.rst b/docs/docsite/rst/inventory/implicit_localhost.rst index 2f065dc7b3b..ced98df8e1d 100644 --- a/docs/docsite/rst/inventory/implicit_localhost.rst +++ b/docs/docsite/rst/inventory/implicit_localhost.rst @@ -5,7 +5,9 @@ Implicit 'localhost' ==================== -When you try to reference a ``localhost`` and you don't have it defined in inventory, Ansible will create an implicit one for you.:: +When you try to reference a ``localhost`` and you don't have it defined in inventory, Ansible will create an implicit one for you.: + +.. code-block:: yaml - hosts: all tasks: @@ -13,7 +15,9 @@ When you try to reference a ``localhost`` and you don't have it defined in inven stat: path=/var/log/hosts/{{inventory_hostname}}.log delegate_to: localhost -In a case like this (or ``local_action``) when Ansible needs to contact a 'localhost' but you did not supply one, we create one for you. This host is defined with specific connection variables equivalent to this in an inventory:: +In a case like this (or ``local_action``) when Ansible needs to contact a 'localhost' but you did not supply one, we create one for you. This host is defined with specific connection variables equivalent to this in an inventory: + +.. code-block:: yaml ... @@ -27,6 +31,7 @@ This ensures that the proper connection and Python are used to execute your task You can override the built-in implicit version by creating a ``localhost`` host entry in your inventory. At that point, all implicit behaviors are ignored; the ``localhost`` in inventory is treated just like any other host. Group and host vars will apply, including connection vars, which includes the ``ansible_python_interpreter`` setting. This will also affect ``delegate_to: localhost`` and ``local_action``, the latter being an alias to the former. .. note:: + - This host is not targetable via any group, however it will use vars from ``host_vars`` and from the 'all' group. - Implicit localhost does not appear in the ``hostvars`` magic variable unless demanded, such as by ``"{{ hostvars['localhost'] }}"``. - The ``inventory_file`` and ``inventory_dir`` magic variables are not available for the implicit localhost as they are dependent on **each inventory host**. diff --git a/docs/docsite/rst/network/getting_started/first_playbook.rst b/docs/docsite/rst/network/getting_started/first_playbook.rst index b09814cd64c..2c06ded7423 100644 --- a/docs/docsite/rst/network/getting_started/first_playbook.rst +++ b/docs/docsite/rst/network/getting_started/first_playbook.rst @@ -95,7 +95,7 @@ The playbook contains one play with two tasks, and should generate output like t $ ansible-playbook -i vyos.example.net, -u ansible -k -e ansible_network_os=vyos.vyos.vyos first_playbook.yml - PLAY [First Playbook] + PLAY [Network Getting Started First Playbook] *************************************************************************************************************************** TASK [Get config for VyOS devices] @@ -113,13 +113,13 @@ The playbook contains one play with two tasks, and should generate output like t .. literalinclude:: sample_files/first_playbook_ext.yml :language: YAML -The extended first playbook has four tasks in a single play. Run it with the same command you used above. The output shows you the change Ansible made to the config: +The extended first playbook has five tasks in a single play. Run it with the same command you used above. The output shows you the change Ansible made to the config: .. code-block:: bash $ ansible-playbook -i vyos.example.net, -u ansible -k -e ansible_network_os=vyos.vyos.vyos first_playbook_ext.yml - PLAY [First Playbook] + PLAY [Network Getting Started First Playbook Extended] ************************************************************************************************************************************ TASK [Get config for VyOS devices] diff --git a/docs/docsite/rst/network/user_guide/cli_parsing.rst b/docs/docsite/rst/network/user_guide/cli_parsing.rst index 56121a443c7..5b6b40ee1ea 100644 --- a/docs/docsite/rst/network/user_guide/cli_parsing.rst +++ b/docs/docsite/rst/network/user_guide/cli_parsing.rst @@ -439,7 +439,7 @@ Parsing with textfsm ``textfsm`` is a Python module which implements a template-based state machine for parsing semi-formatted text. -The following sample``textfsm`` template is stored as ``templates/nxos_show_interface.textfsm`` +The following sample ``textfsm`` template is stored as ``templates/nxos_show_interface.textfsm`` .. code-block:: text diff --git a/docs/docsite/rst/playbook_guide/playbooks_filters.rst b/docs/docsite/rst/playbook_guide/playbooks_filters.rst index 90cdae1eb8e..1b5a7d1bdee 100644 --- a/docs/docsite/rst/playbook_guide/playbooks_filters.rst +++ b/docs/docsite/rst/playbook_guide/playbooks_filters.rst @@ -2132,7 +2132,9 @@ To format a date using a string (like with the shell date command), use the "str .. versionadded:: 2.13 -strftime takes an optional utc argument, defaulting to False, meaning times are in the local timezone:: +strftime takes an optional utc argument, defaulting to False, meaning times are in the local timezone: + +.. code-block:: yaml+jinja {{ '%H:%M:%S' | strftime }} # time now in local timezone {{ '%H:%M:%S' | strftime(utc=True) }} # time now in UTC diff --git a/docs/docsite/rst/reference_appendices/python_3_support.rst b/docs/docsite/rst/reference_appendices/python_3_support.rst index 5d18b093935..e7196d2aaa4 100644 --- a/docs/docsite/rst/reference_appendices/python_3_support.rst +++ b/docs/docsite/rst/reference_appendices/python_3_support.rst @@ -6,7 +6,7 @@ Ansible 2.5 and above work with Python 3. Previous to 2.5, using Python 3 was considered a tech preview. This topic discusses how to set up your controller and managed machines to use Python 3. -.. note:: On the controller we support Python 3.5 or greater and Python 2.7 or greater. Module-side, we support Python 3.5 or greater and Python 2.6 or greater. +See :ref: `Control Node Requirements ` and :ref: `Managed Node Requirements ` for the specific versions supported. On the controller side ---------------------- @@ -18,7 +18,7 @@ version of pip. This will make the default :command:`/usr/bin/ansible` run with $ pip3 install ansible $ ansible --version | grep "python version" - python version = 3.6.2 (default, Sep 22 2017, 08:28:09) [GCC 7.2.1 20170915 (Red Hat 7.2.1-2)] + python version = 3.10.5 (main, Jun 9 2022, 00:00:00) [GCC 12.1.1 20220507 (Red Hat 12.1.1-1)] (/usr/bin/python) If you are running Ansible :ref:`from_source` and want to use Python 3 with your source checkout, run your command through ``python3``. For example: diff --git a/lib/ansible/config/base.yml b/lib/ansible/config/base.yml index a824ec2e734..664eb107015 100644 --- a/lib/ansible/config/base.yml +++ b/lib/ansible/config/base.yml @@ -924,7 +924,7 @@ DEFAULT_NO_TARGET_SYSLOG: default: False description: - Toggle Ansible logging to syslog on the target when it executes tasks. On Windows hosts this will disable a newer - style PowerShell modules from writting to the event log. + style PowerShell modules from writing to the event log. env: [{name: ANSIBLE_NO_TARGET_SYSLOG}] ini: - {key: no_target_syslog, section: defaults} @@ -1457,7 +1457,7 @@ GALAXY_IGNORE_INVALID_SIGNATURE_STATUS_CODES: - section: galaxy key: ignore_signature_status_codes description: - - A list of GPG status codes to ignore during GPG signature verfication. + - A list of GPG status codes to ignore during GPG signature verification. See L(https://github.com/gpg/gnupg/blob/master/doc/DETAILS#general-status-codes) for status code descriptions. - If fewer signatures successfully verify the collection than `GALAXY_REQUIRED_VALID_SIGNATURE_COUNT`, signature verification will fail even if all error codes are ignored. diff --git a/lib/ansible/executor/task_executor.py b/lib/ansible/executor/task_executor.py index 6718f31085d..1f35031f8c1 100644 --- a/lib/ansible/executor/task_executor.py +++ b/lib/ansible/executor/task_executor.py @@ -556,7 +556,7 @@ class TaskExecutor: plugin_vars = self._set_connection_options(cvars, templar) # make a copy of the job vars here, as we update them here and later, - # but don't want to polute original + # but don't want to pollute original vars_copy = variables.copy() # update with connection info (i.e ansible_host/ansible_user) self._connection.update_vars(vars_copy) @@ -578,7 +578,7 @@ class TaskExecutor: setattr(self._connection, '_socket_path', socket_path) # TODO: eventually remove this block as this should be a 'consequence' of 'forced_local' modules - # special handling for python interpreter for network_os, default to ansible python unless overriden + # special handling for python interpreter for network_os, default to ansible python unless overridden if 'ansible_network_os' in cvars and 'ansible_python_interpreter' not in cvars: # this also avoids 'python discovery' cvars['ansible_python_interpreter'] = sys.executable @@ -802,7 +802,7 @@ class TaskExecutor: # add the delegated vars to the result, so we can reference them # on the results side without having to do any further templating - # also now add conneciton vars results when delegating + # also now add connection vars results when delegating if self._task.delegate_to: result["_ansible_delegated_vars"] = {'ansible_delegated_host': self._task.delegate_to} for k in plugin_vars: diff --git a/lib/ansible/galaxy/dependency_resolution/dataclasses.py b/lib/ansible/galaxy/dependency_resolution/dataclasses.py index 60015dbfe76..16fd6318f86 100644 --- a/lib/ansible/galaxy/dependency_resolution/dataclasses.py +++ b/lib/ansible/galaxy/dependency_resolution/dataclasses.py @@ -193,7 +193,7 @@ class _ComputedReqKindsMixin: falls back to guessing the FQCN based on the directory path and sets the version to "*". - It raises a ValueError immediatelly if the input is not an + It raises a ValueError immediately if the input is not an existing directory path. """ if not os.path.isdir(dir_path): diff --git a/lib/ansible/module_utils/common/locale.py b/lib/ansible/module_utils/common/locale.py index e8b201b23ea..a6068c8666a 100644 --- a/lib/ansible/module_utils/common/locale.py +++ b/lib/ansible/module_utils/common/locale.py @@ -56,6 +56,6 @@ def get_best_parsable_locale(module, preferences=None, raise_on_locale=False): else: module.debug('Failed to get locale information: %s' % to_native(e)) - module.debug('Matched prefered locale to: %s' % found) + module.debug('Matched preferred locale to: %s' % found) return found diff --git a/lib/ansible/modules/apt_key.py b/lib/ansible/modules/apt_key.py index f4a4126dcbd..18b8834469d 100644 --- a/lib/ansible/modules/apt_key.py +++ b/lib/ansible/modules/apt_key.py @@ -28,7 +28,7 @@ attributes: platforms: debian notes: - The apt-key command has been deprecated and suggests to 'manage keyring files in trusted.gpg.d instead'. See the Debian wiki for details. - This module is kept for backwards compatiblity for systems that still use apt-key as the main way to manage apt repository keys. + This module is kept for backwards compatibility for systems that still use apt-key as the main way to manage apt repository keys. - As a sanity check, downloaded key id must match the one specified. - "Use full fingerprint (40 characters) key ids to avoid key collisions. To generate a full-fingerprint imported key: C(apt-key adv --list-public-keys --with-fingerprint --with-colons)." @@ -160,7 +160,7 @@ key_id: type: str sample: "36A1D7869245C8950F966E92D8576A8BA88D21E9" short_id: - description: caclulated short key id + description: calculated short key id returned: always type: str sample: "A88D21E9" diff --git a/lib/ansible/modules/apt_repository.py b/lib/ansible/modules/apt_repository.py index de7586cd7a7..09d45e2c008 100644 --- a/lib/ansible/modules/apt_repository.py +++ b/lib/ansible/modules/apt_repository.py @@ -142,8 +142,8 @@ EXAMPLES = ''' - name: somerepo | apt source ansible.builtin.apt_repository: - repo: "deb [arch=amd64 signed-by=/etc/apt/trusted.gpg.d/somerepo.asc] https://download.example.com/linux/ubuntu {{ ansible_distribution_release }} stable" - state: present + repo: "deb [arch=amd64 signed-by=/etc/apt/trusted.gpg.d/myrepo.asc] https://download.example.com/linux/ubuntu {{ ansible_distribution_release }} stable" + state: present ''' RETURN = '''#''' diff --git a/lib/ansible/modules/include_vars.py b/lib/ansible/modules/include_vars.py index d341df0050e..f0aad94ad44 100644 --- a/lib/ansible/modules/include_vars.py +++ b/lib/ansible/modules/include_vars.py @@ -90,7 +90,7 @@ extends_documentation_fragment: - action_core attributes: action: - details: While the action plugin does do some of the work it relies on the core engine to actually create the variables, that part cannot be overriden + details: While the action plugin does do some of the work it relies on the core engine to actually create the variables, that part cannot be overridden support: partial bypass_host_loop: support: none diff --git a/lib/ansible/modules/set_fact.py b/lib/ansible/modules/set_fact.py index 74ea5cdf051..5609e5bc189 100644 --- a/lib/ansible/modules/set_fact.py +++ b/lib/ansible/modules/set_fact.py @@ -33,7 +33,7 @@ options: (by 7 steps) of the variable created. U(https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable) - "This actually creates 2 copies of the variable, a normal 'set_fact' host variable with high precedence and - a lower 'ansible_fact' one that is available for persistance via the facts cache plugin. + a lower 'ansible_fact' one that is available for persistence via the facts cache plugin. This creates a possibly confusing interaction with C(meta: clear_facts) as it will remove the 'ansible_fact' but not the host variable." type: bool default: no diff --git a/lib/ansible/modules/set_stats.py b/lib/ansible/modules/set_stats.py index 3fa0975cddc..2fd21da143d 100644 --- a/lib/ansible/modules/set_stats.py +++ b/lib/ansible/modules/set_stats.py @@ -38,7 +38,7 @@ extends_documentation_fragment: - action_core attributes: action: - details: While the action plugin does do some of the work it relies on the core engine to actually create the variables, that part cannot be overriden + details: While the action plugin does do some of the work it relies on the core engine to actually create the variables, that part cannot be overridden support: partial bypass_host_loop: support: none diff --git a/lib/ansible/plugins/loader.py b/lib/ansible/plugins/loader.py index dbaa6677307..d09138b12f3 100644 --- a/lib/ansible/plugins/loader.py +++ b/lib/ansible/plugins/loader.py @@ -1280,10 +1280,10 @@ class Jinja2Loader(PluginLoader): raise AnsibleError('Do not set both path_only and class_only when calling PluginLoader.all()') found = set() - # get plugins from files in configured paths (mulitple in each) + # get plugins from files in configured paths (multiple in each) for p_map in self._j2_all_file_maps(*args, **kwargs): - # p_map is really object from file with class that holds mulitple plugins + # p_map is really object from file with class that holds multiple plugins plugins_list = getattr(p_map, self.method_map_name) try: plugins = plugins_list()