Compare commits
19 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 5d9d0fe39b | |||
| 9a7b645c50 | |||
| cad892125c | |||
| e03069a444 | |||
| 91fb18bf31 | |||
| 3e1db5d753 | |||
| e51e36ea6a | |||
| 9deb5ad45a | |||
| 8dedf7f06c | |||
| 220917e2af | |||
| 2cba3e8c42 | |||
| c4901aa08f | |||
| bd1da60bf2 | |||
| 30f96bb75e | |||
| 3b20b02272 | |||
| 6b6b324618 | |||
| f720c58949 | |||
| 85341c3e5d | |||
| ee9705a1ce |
339
changelogs/CHANGELOG-v2.13.rst
Normal file
339
changelogs/CHANGELOG-v2.13.rst
Normal file
@ -0,0 +1,339 @@
|
||||
=========================================================
|
||||
ansible-core 2.13 "Nobody's Fault but Mine" Release Notes
|
||||
=========================================================
|
||||
|
||||
.. contents:: Topics
|
||||
|
||||
|
||||
v2.13.0b1
|
||||
=========
|
||||
|
||||
Release Summary
|
||||
---------------
|
||||
|
||||
| Release Date: 2022-04-25
|
||||
| `Porting Guide <https://docs.ansible.com/ansible/devel/porting_guides.html>`__
|
||||
|
||||
|
||||
Minor Changes
|
||||
-------------
|
||||
|
||||
- ansible-test - Update ``default`` containers to version 5.9.0.
|
||||
|
||||
Bugfixes
|
||||
--------
|
||||
|
||||
- ansible - Exclude Python 2.6 from Python interpreter discovery.
|
||||
- arg_spec - Fix incorrect ``no_log`` warning when a parameter alias is used (https://github.com/ansible/ansible/pull/77576)
|
||||
- variablemanager, more efficient read of vars files
|
||||
|
||||
v2.13.0b0
|
||||
=========
|
||||
|
||||
Release Summary
|
||||
---------------
|
||||
|
||||
| Release Date: 2022-04-11
|
||||
| `Porting Guide <https://docs.ansible.com/ansible/devel/porting_guides.html>`__
|
||||
|
||||
|
||||
Major Changes
|
||||
-------------
|
||||
|
||||
- Jinja2 Controller Requirement - Jinja2 3.0.0 or newer is required for the control node (the machine that runs Ansible) (https://github.com/ansible/ansible/pull/75881)
|
||||
- Templating - remove ``safe_eval`` in favor of using ``NativeEnvironment`` but utilizing ``literal_eval`` only in cases when ``safe_eval`` was used (https://github.com/ansible/ansible/pull/75587)
|
||||
|
||||
Minor Changes
|
||||
-------------
|
||||
|
||||
- Action Plugins - Add helper method for argument spec validation, and extend to pause and async_wrapper
|
||||
- Added AIX root CA certs folders - enhance the TLS support in ``uri`` task on AIX
|
||||
- Added ``module_utils.compat.typing`` to facilitate type-hinting on all supported Python versions.
|
||||
- Ansible.Basic - small changes to allow use in PowerShell modules running on non-Windows platforms (https://github.com/ansible/ansible/pull/76924).
|
||||
- AnsibleModule.run_command() now has a toggle to allow caller to decide to handle exceptions from executing the command itself
|
||||
- Attach concat function to an environment class (https://github.com/ansible/ansible/pull/76282)
|
||||
- Clarify in a comment that unrolling an iterator in ``Templar._finalize`` is actually necessary. Also switch to using the ``_unroll_iterator`` decorator directly to deduplicate code in ``Templar._finalize``. (https://github.com/ansible/ansible/pull/76436)
|
||||
- Installation - modernize our python installation, to reduce dynamic code in setup.py, and migrate what is feasible to setup.cfg. This will enable shipping wheels in the future.
|
||||
- PlayIterator - introduce public methods to access ``PlayIterator._host_states`` (https://github.com/ansible/ansible/pull/74416)
|
||||
- PlayIterator - use enums for Iterating and Failed states (https://github.com/ansible/ansible/pull/74511)
|
||||
- Reduce number of iterations through PlayIterator (https://github.com/ansible/ansible/pull/74175)
|
||||
- Remove more Python 2.x compatibility code from controller (https://github.com/ansible/ansible/pull/77320).
|
||||
- Start of moving away from using Six, Python 2 and 3 compatibility library (https://github.com/ansible/ansible/pull/75863)
|
||||
- The collection loader now reports a Python warning if an attempt is made to install the Ansible collection loader a second time. Previously this condition was reported using an Ansible warning.
|
||||
- ``ansible-galaxy collection [install|verify]`` - allow user-provided signature sources in addition to those from the Galaxy server. Each collection entry in a requirements file can specify a ``signatures`` key followed by a list of sources. Collection name(s) provided on the CLI can specify additional signature sources by using the ``--signatures`` CLI option. Signature sources should be URIs that can be opened with ``urllib.request.urlopen()``, such as "https://example.com/path/to/detached_signature.asc" or "file:///path/to/detached_signature.asc". The ``--keyring`` option must be specified if signature sources are provided.
|
||||
- ``ansible-galaxy collection [install|verify]`` - use gpg to verify the authenticity of the signed ``MANIFEST.json`` with ASCII armored detached signatures provided by the Galaxy server. The keyring (which is not managed by ``ansible-galaxy``) must be provided with the ``--keyring`` option to use signature verification. If no ``--keyring`` is specified and the collection to ``install|verify`` has associated detached signatures on the Galaxy server, a warning is provided.
|
||||
- ``ansible-galaxy collection install`` - Add a global configuration to modify the required number of signatures that must verify the authenticity of the collection. By default, the number of required successful signatures is 1. Set this option to ``all`` to require all signatures verify the collection. To ensure signature verification fails if there are no valid signatures, prepend the value with '+', such as ``+all`` or ``+1``.
|
||||
- ``ansible-galaxy collection install`` - Add a global ignore list for gpg signature errors. This can be used to ignore certain signatures when the number of required successful signatures is all. When the required number of successful signatures is a positive integer, the only effect this has is to display fewer errors to the user on failure (success is determined by having the minimum number of successful signatures, in which case all errors are disregarded).
|
||||
- ``ansible-galaxy collection install`` - Add a global toggle to turn off GPG signature verification.
|
||||
- ``ansible-galaxy collection install`` - Store Galaxy server metadata alongside installed collections for provenance. Signatures obtained from the Galaxy server can be used for offline verification with ``ansible-galaxy collection verify --offline``.
|
||||
- ansible-console - Provide a way to customize the stdout callback
|
||||
- ansible-core modules - Remove unused Python shebangs from built-in modules.
|
||||
- ansible-doc metadata dump - add option ``--no-fail-on-errors`` which allows to not fail the ansible-doc invocation when errors happen during docs parsing or processing. Instead they are reported in the JSON result in an ``error`` key for the affected plugins (https://github.com/ansible/ansible/pull/77035).
|
||||
- ansible-galaxy - the option to skip certificate verification now also applies when cloning via SCM (git/hg) (https://github.com/ansible/ansible/issues/41077)
|
||||
- ansible-test - Accept new-style Python modules without a shebang.
|
||||
- ansible-test - Add ``--version`` support to show the ansible-core version.
|
||||
- ansible-test - Add support for ``rhel/8.5`` remote instances.
|
||||
- ansible-test - Add support for remote testing of FreeBSD 12.3.
|
||||
- ansible-test - Add support for running container tests with ``podman remote`` (https://github.com/ansible/ansible/pull/75753)
|
||||
- ansible-test - Added the ``fedora35`` test container.
|
||||
- ansible-test - Change the maximum number of open files in a test container from the default to ``10240``.
|
||||
- ansible-test - Declare public dependencies of ansible-core and use to limit unguarded imports in plugins.
|
||||
- ansible-test - Importing ``distutils`` now results in an error.
|
||||
- ansible-test - Installation of ``cryptography`` is no longer version constrained when ``openssl`` 1.1.0 or later is installed.
|
||||
- ansible-test - Miscellaneous code cleanup and type hint fixes.
|
||||
- ansible-test - PowerShell in the ``base`` and ``default`` containers has been upgraded to version 7.1.4.
|
||||
- ansible-test - Remove RHEL 8.4 remote (``rhel/8.4``) support.
|
||||
- ansible-test - Remove ``idna`` constraint.
|
||||
- ansible-test - Remove obsolete ``MAXFD`` display.
|
||||
- ansible-test - Remove obsolete constraints for Python 2.6.
|
||||
- ansible-test - Remove support for FreeBSD 12.2 remote provisioning.
|
||||
- ansible-test - Remove support for macOS 11.1 remote provisioning.
|
||||
- ansible-test - Remove support for provisioning remote AIX instances.
|
||||
- ansible-test - Remove the ``centos8`` test container since CentOS 8 will reach end-of-life soon.
|
||||
- ansible-test - Remove the ``fedora33`` test container since Fedora 33 will reach end-of-life soon.
|
||||
- ansible-test - Remove unused Python 2.x compatibility code.
|
||||
- ansible-test - Removed support for Sherlock from the Azure provisioning plugin.
|
||||
- ansible-test - Removed used ``MarkupSafe`` constraint for Python 3.5 and earlier.
|
||||
- ansible-test - Requirements for the plugin import test are now frozen.
|
||||
- ansible-test - Shellcheck in the ``base`` and ``default`` containers has been upgraded to version 0.7.0.
|
||||
- ansible-test - Stop early with an error if the current working directory contains an invalid collection namespace or name.
|
||||
- ansible-test - The ``--help`` option is now available when an unsupported cwd is in use.
|
||||
- ansible-test - The ``--help`` output now shows the same instructions about cwd as would be shown in error messages if the cwd is unsupported.
|
||||
- ansible-test - The ``pip`` and ``wheel`` packages are removed from all sanity test virtual environments after installation completes to reduce their size. Previously they were only removed from the environments used for the ``import`` sanity test.
|
||||
- ansible-test - The explanation about cwd usage has been improved to explain more clearly what is required.
|
||||
- ansible-test - The hash for all managed sanity test virtual environments has changed. Containers that include ``ansible-test sanity --prime-venvs`` will need to be rebuilt to continue using primed virtual environments.
|
||||
- ansible-test - Update ``base`` container to version 2.1.0.
|
||||
- ansible-test - Update ``base`` container to version 2.2.0.
|
||||
- ansible-test - Update ``default`` containers to version 5.2.0.
|
||||
- ansible-test - Update ``default`` containers to version 5.4.0.
|
||||
- ansible-test - Update ``default`` containers to version 5.5.0.
|
||||
- ansible-test - Update ``default`` containers to version 5.6.2.
|
||||
- ansible-test - Update ``default`` containers to version 5.7.0.
|
||||
- ansible-test - Update ``default`` containers to version 5.8.0.
|
||||
- ansible-test - Update ``pip`` used to bootstrap remote FreeBSD instances from version 20.3.4 to 21.3.1.
|
||||
- ansible-test - Update sanity test requirements.
|
||||
- ansible-test - Update the NIOS test plugin container to version 1.4.0.
|
||||
- ansible-test - Update the ``alpine`` container to version 3.3.0. This updates the base image from 3.14.2 to 3.15.0, which includes support for installing binary wheels using pip.
|
||||
- ansible-test - Update the ``base`` and ``default`` containers from Python 3.10.0rc2 to 3.10.0.
|
||||
- ansible-test - Update the ``base`` and ``default`` containers from a Ubuntu 18.04 to Ubuntu 20.04 base image.
|
||||
- ansible-test - Update the ``default`` containers to version 5.1.0.
|
||||
- ansible-test - Update the ``galaxy`` test plugin to get its container from a copy on quay.io.
|
||||
- ansible-test - Update the ``openshift`` test plugin to get its container from a copy on quay.io.
|
||||
- ansible-test - Use Python 3.10 as the default Python version for the ``base`` and ``default`` containers.
|
||||
- ansible-test - add macOS 12.0 as a remote target (https://github.com/ansible/ansible/pull/76328)
|
||||
- ansible-test - handle JSON decode error gracefully in podman environment.
|
||||
- ansible-test pslint - Added the `AvoidLongLines <https://github.com/PowerShell/PSScriptAnalyzer/blob/master/docs/Rules/AvoidLongLines.md>`_ rule set to a length of 160.
|
||||
- ansible-test pslint - Added the `PlaceCloseBrace <https://github.com/PowerShell/PSScriptAnalyzer/blob/master/docs/Rules/PlaceCloseBrace.md>`_ rule set to enforce close braces on a newline.
|
||||
- ansible-test pslint - Added the `PlaceOpenBrace <https://github.com/PowerShell/PSScriptAnalyzer/blob/master/docs/Rules/PlaceOpenBrace.md>`_ rule set to enforce open braces on the same line and a subsequent newline.
|
||||
- ansible-test pslint - Added the `UseConsistentIndentation <https://github.com/PowerShell/PSScriptAnalyzer/blob/master/docs/Rules/UseConsistentIndentation.md>`_ rule to enforce indentation is done with 4 spaces.
|
||||
- ansible-test pslint - Added the `UseConsistentWhitespace <https://github.com/PowerShell/PSScriptAnalyzer/blob/master/docs/Rules/UseConsistentWhitespace.md>`_ rule to enforce whitespace consistency in PowerShell.
|
||||
- ansible-test pslint - Updated ``PowerShellScriptAnalyzer`` to 1.20.0
|
||||
- ansible-test sanity validate-modules - the validate-modules sanity test now also checks the documentation of documentable plugin types (https://github.com/ansible/ansible/pull/71734).
|
||||
- ansible-test validate-modules sanity test - add more schema checks to improve quality of plugin documentation (https://github.com/ansible/ansible/pull/77268).
|
||||
- ansible-test validate_modules - allow ``choices`` for return values (https://github.com/ansible/ansible/pull/76009).
|
||||
- apt - Add support for using ">=" in package version number matching.
|
||||
- apt - Adds APT option ``--allow-change-held-packages`` as module parameter ``allow_change_held_packages`` to allow APT up- or downgrading a package which is on APTs hold list (https://github.com/ansible/ansible/issues/65325)
|
||||
- auto inventory plugin will now give plugin loading information on verbose output
|
||||
- callbacks - Add result serialization format options to ``_dump_results`` allowing plugins such as the ``default`` callback to emit ``YAML`` serialized task results in addition to ``JSON``
|
||||
- dnf - add more specific error message for GPG validation (https://github.com/ansible/ansible/issues/76192)
|
||||
- env lookup, add default option
|
||||
- facts - report prefix length for IPv4 addresses in Linux network facts.
|
||||
- get_parsable_locale now logs result when in debug mode.
|
||||
- git - display the destination directory path in error msg when local_mods detects local modifications conflict so that users see the exact location
|
||||
- iptables - add the ``chain_management`` parameter that controls iptables chain creation and deletion
|
||||
- jinja2_native - keep same behavior on Python 3.10.
|
||||
- junit callback - Add support for replacing the directory portion of out-of-tree relative task paths with a placeholder.
|
||||
- k8s - scenario guides for kubernetes migrated to ``kubernetes.core`` collection.
|
||||
- module_utils.distro - Add missing ``typing`` import from original code.
|
||||
- package_facts - add pkg_info support for OpenBSD and NetBSD (https://github.com/ansible/ansible/pull/76580)
|
||||
- services_facts - Add support for openrc (https://github.com/ansible/ansible/pull/76373).
|
||||
- setting DEFAULT_FACT_PATH is being deprecated in favor of the generic module_defaults keyword
|
||||
- uri - Avoid reading the response body when not needed
|
||||
- uri - Eliminate multiple requests to determine the final URL for file naming with ``dest``
|
||||
- validate-modules - do some basic validation on the ``M(...)``, ``U(...)``, ``L(..., ...)`` and ``R(..., ...)`` documentation markups (https://github.com/ansible/ansible/pull/76262).
|
||||
- vmware - migrated vmware scenario guides to `community.vmware` repo.
|
||||
- yum, dnf - add sslverify option to temporarily disable certificate validation for a repository
|
||||
|
||||
Breaking Changes / Porting Guide
|
||||
--------------------------------
|
||||
|
||||
- Module Python Dependency - Drop support for Python 2.6 in module execution.
|
||||
- Templating - it is no longer allowed to perform arithmetic and concatenation operations outside of the jinja template (https://github.com/ansible/ansible/pull/75587)
|
||||
- The ``finalize`` method is no longer exposed in the globals for use in templating.
|
||||
|
||||
Deprecated Features
|
||||
-------------------
|
||||
|
||||
- ansible-core - Remove support for Python 2.6.
|
||||
- ansible-test - Remove support for Python 2.6.
|
||||
- ssh connection plugin option scp_if_ssh in favor of ssh_transfer_method.
|
||||
|
||||
Removed Features (previously deprecated)
|
||||
----------------------------------------
|
||||
|
||||
- Remove deprecated ``Templar.set_available_variables()`` method (https://github.com/ansible/ansible/issues/75828)
|
||||
- cli - remove deprecated ability to set verbosity before the sub-command (https://github.com/ansible/ansible/issues/75823)
|
||||
- copy - remove deprecated ``thirsty`` alias (https://github.com/ansible/ansible/issues/75824)
|
||||
- psrp - Removed fallback on ``put_file`` with older ``pypsrp`` versions. Users must have at least ``pypsrp>=0.4.0``.
|
||||
- url_argument_spec - remove deprecated ``thirsty`` alias for ``get_url`` and ``uri`` modules (https://github.com/ansible/ansible/issues/75825, https://github.com/ansible/ansible/issues/75826)
|
||||
|
||||
Security Fixes
|
||||
--------------
|
||||
|
||||
- Do not include params in exception when a call to ``set_options`` fails. Additionally, block the exception that is returned from being displayed to stdout. (CVE-2021-3620)
|
||||
|
||||
Bugfixes
|
||||
--------
|
||||
|
||||
- Add a YAML representer for ``NativeJinjaText``
|
||||
- Add a YAML representer for ``NativeJinjaUnsafeText``
|
||||
- AnsiballZ - Ensure we use the full python package in the module cache filename to avoid a case where ``collections:`` is used to execute a module via short name, where the short name duplicates another module from ``ansible.builtin`` or another collection that was executed previously.
|
||||
- Ansible.ModuleUtils.LinkUtil - Ignore the ``LIB`` environment variable when loading the ``LinkUtil`` code
|
||||
- Ansible.ModuleUtils.SID - Use user principal name as is for lookup in the ``Convert-ToSID`` function - https://github.com/ansible/ansible/issues/77316
|
||||
- Detect package manager for Amazon Linux 2022 (AL2022) as dnf
|
||||
- Ensure the correct ``environment_class`` is set on ``AnsibleJ2Template``
|
||||
- Fix ``AttributeError`` when providing password file via ``--connection-password-file`` (https://github.com/ansible/ansible/issues/76530)
|
||||
- Fix ``end_play`` to end the current play only (https://github.com/ansible/ansible/issues/76672)
|
||||
- Fix collection filter/test plugin redirects (https://github.com/ansible/ansible/issues/77192).
|
||||
- Fix executing includes in the always section in the free strategy (https://github.com/ansible/ansible/issues/75642)
|
||||
- Fix for when templating empty template file resulted in file with string 'None' (https://github.com/ansible/ansible/issues/76610)
|
||||
- Fix help message for the 'ansible-galaxy collection verify' positional argument. The positional argument must be a collection name (https://github.com/ansible/ansible/issues/76087).
|
||||
- Fix module logging issue when using custom module on WSL2 (https://github.com/ansible/ansible/issues/76320)
|
||||
- Fix task debugger to work with ``run_once`` using ``linear`` strategy (https://github.com/ansible/ansible/issues/76049)
|
||||
- Fix traceback when installing a collection from a git repository and git is not installed (https://github.com/ansible/ansible/issues/77479).
|
||||
- Interpreter Discovery - Fallback to OS family if the distro is not found in ``INTERPRETER_PYTHON_DISTRO_MAP`` (https://github.com/ansible/ansible/issues/75560)
|
||||
- Interpreter discovery - Add ``RHEL`` to ``OS_FAMILY_MAP`` for correct family fallback for interpreter discovery (https://github.com/ansible/ansible/issues/77368)
|
||||
- Make include_role/include_tasks work with any_errors_fatal (https://github.com/ansible/ansible/issues/50897)
|
||||
- Parser errors from within includes should not be rescueable (https://github.com/ansible/ansible/issues/73657)
|
||||
- Templating - Ensure we catch exceptions when getting ``.filters`` and ``.tests`` attributes on their respective plugins and properly error, instead of aborting which results in no filters being added to the jinja2 environment
|
||||
- Trigger an undefined error when an undefined variable is detected within a dictionary and/or list (https://github.com/ansible/ansible/pull/75587)
|
||||
- _run_loop - Add the task name to the warning (https://github.com/ansible/ansible/issues/76011)
|
||||
- ``Templar.copy_with_new_env`` - set the ``finalize`` method of the new ``Templar`` object for the new environment (https://github.com/ansible/ansible/issues/76379)
|
||||
- add_host/group_by: fix using changed_when in a loop (https://github.com/ansible/ansible/issues/71627)
|
||||
- ansible-config avoid showing _terms and _input when --only-changed.
|
||||
- ansible-doc - Fix ansible-doc -l ansible.builtin / ansible.legacy not returning anything
|
||||
- ansible-doc - ignore plugin deprecation warnings (https://github.com/ansible/ansible/issues/75671)
|
||||
- ansible-galaxy - Add galaxy_collection_skeleton/galaxy_collection_skeleton_ignore configuration options
|
||||
- ansible-galaxy - Fix using the '--ignore-certs' option when there is no server-specific configuration for the Galaxy server.
|
||||
- ansible-galaxy - installing/downloading collections with invalid versions in git repositories and directories now gives a formatted error message (https://github.com/ansible/ansible/issues/76425, https://github.com/ansible/ansible/issues/75404).
|
||||
- ansible-galaxy - when installing a role properly raise an error when inaccessible path is specified multiple times in roles_path (e.g. via environment variable and command line option) (https://github.com/ansible/ansible/issues/76316)
|
||||
- ansible-galaxy collection build - Ignore any existing ``MANIFEST.json`` and ``FILES.json`` in the root directory when building a collection.
|
||||
- ansible-galaxy collection verify - display files/directories not included in the FILES.json as modified content.
|
||||
- ansible-galaxy publish - Fix warning and error detection in import messages to properly display them in Ansible
|
||||
- ansible-pull handle case where hostname and nodename are empty
|
||||
- ansible-test - Add default entry for Windows remotes to be used with unknown versions.
|
||||
- ansible-test - All virtual environments managed by ansible-test are marked as usable after being bootstrapped, to avoid errors caused by use of incomplete environments. Previously this was only done for sanity tests. Existing environments from previous versions of ansible-test will be recreated on demand due to lacking the new marker.
|
||||
- ansible-test - Automatic target requirements installation is now based on the target environment instead of the controller environment.
|
||||
- ansible-test - Correctly detect when running as the ``root`` user (UID 0) on the origin host. The result of the detection was incorrectly being inverted.
|
||||
- ansible-test - Don't fail if network cannot be disconnected (https://github.com/ansible/ansible/pull/77472)
|
||||
- ansible-test - Fix Python real prefix detection when running in a ``venv`` virtual environment.
|
||||
- ansible-test - Fix ``windows-integration`` and ``network-integration`` when used with the ``--docker`` option and user-provided inventory.
|
||||
- ansible-test - Fix installation and usage of ``pyyaml`` requirement for the ``import`` sanity test for collections.
|
||||
- ansible-test - Fix path to inventory file for ``windows-integration`` and ``network-integration`` commands for collections.
|
||||
- ansible-test - Fix plugin loading.
|
||||
- ansible-test - Fix skipping of tests marked ``needs/python`` on the origin host.
|
||||
- ansible-test - Fix skipping of tests marked ``needs/root`` on the origin host.
|
||||
- ansible-test - Fix the ``import`` sanity test to work properly when Ansible's built-in vendoring support is in use.
|
||||
- ansible-test - Fix the ``validate-modules`` sanity test to avoid double-loading the collection loader and possibly failing on import of the ``packaging`` module.
|
||||
- ansible-test - Fix traceback in ``import`` sanity test on Python 2.7 when ``pip`` is not available.
|
||||
- ansible-test - Fix traceback in the ``validate-modules`` sanity test when testing an Ansible module without any callables.
|
||||
- ansible-test - Fix traceback when running from an install and delegating execution to a different Python interpreter.
|
||||
- ansible-test - Fix traceback when using the ``--all`` option with PowerShell code coverage.
|
||||
- ansible-test - Fix type hints.
|
||||
- ansible-test - Import ``yaml.cyaml.CParser`` instead of ``_yaml.CParser`` in the ``yamllint`` sanity test.
|
||||
- ansible-test - Limit ``paramiko`` installation to versions before 2.9.0. This is required to maintain support for systems which do not support RSA SHA-2 algorithms.
|
||||
- ansible-test - Pylint Deprecated Plugin - Use correct message symbols when date or version is not a float or str (https://github.com/ansible/ansible/issues/77085)
|
||||
- ansible-test - Relocate constants to eliminate symlink.
|
||||
- ansible-test - Replace the directory portion of out-of-tree paths in JUnit files from integration tests with the ``out-of-tree:`` prefix.
|
||||
- ansible-test - Sanity tests run with the ``--requirements` option for Python 2.x now install ``virtualenv`` when it is missing or too old. Previously it was only installed if missing. Version 16.7.12 is now installed instead of the latest version.
|
||||
- ansible-test - Set the ``pytest`` option ``--rootdir`` instead of letting it be auto-detected.
|
||||
- ansible-test - Show an error message instead of a traceback when running outside of a supported directory.
|
||||
- ansible-test - Target integration test requirements are now correctly installed for target environments running on the controller.
|
||||
- ansible-test - The ``import`` sanity test no longer reports errors about ``packaging`` being missing when testing collections.
|
||||
- ansible-test - Update distribution test containers to version 3.1.0.
|
||||
- ansible-test - Update help links to reference ``ansible-core`` instead of ``ansible``.
|
||||
- ansible-test - Update unit tests to use the ``--forked`` option instead of the deprecated ``--boxed`` option.
|
||||
- ansible-test - Use https://ci-files.testing.ansible.com/ for instance bootstrapping instead of an S3 endpoint.
|
||||
- ansible-test - Use relative paths in JUnit files generated during integration test runs.
|
||||
- ansible-test - Use the correct variable to reference the client's SSH key when generating inventory.
|
||||
- ansible-test - Use the legacy collection loader for ``import`` sanity tests on target-only Python versions.
|
||||
- ansible-test - Virtual environments managed by ansible-test now use consistent versions of ``pip``, ``setuptools`` and ``wheel``. This avoids issues with virtual environments containing outdated or dysfunctional versions of these tools. The initial bootstrapping of ``pip`` is done by ansible-test from an HTTPS endpoint instead of creating the virtual environment with it already present.
|
||||
- ansible-test - fix a typo in validate-modules.
|
||||
- ansible-test - fixed support container failures (eg http-test-container) under podman
|
||||
- ansible-test compile sanity test - do not crash if a column could not be determined for an error (https://github.com/ansible/ansible/pull/77465).
|
||||
- ansible-test pslint - Fix error when encountering validation results that are highly nested - https://github.com/ansible/ansible/issues/74151
|
||||
- ansible-vault encrypt_string - fix ``--output`` option to correctly write encrypted string into given file (https://github.com/ansible/ansible/issues/75101)
|
||||
- ansible.builtin.file modification_time supports check_mode
|
||||
- ansible_facts.devices - Fix parsing of device serial number detected via sg_inq for rhel8 (https://github.com/ansible/ansible/issues/75420)
|
||||
- apt - fails to deploy deb file to old debian systems using python-apt < 0.8.9 (https://github.com/ansible/ansible/issues/47277)
|
||||
- async - Improve performance of sending async callback events by never sending the full task through the queue (https://github.com/ansible/ansible/issues/76729)
|
||||
- catch the case that cowsay is broken which would lead to missing output
|
||||
- cleaning facts will now only warn about the variable name and not post the content, which can be undesireable to disclose
|
||||
- collection_loader - Implement 'find_spec' and 'exec_module' to override deprecated importlib methods 'find_module' and 'load_module' when applicable (https://github.com/ansible/ansible/issues/74660).
|
||||
- correctly inherit vars from parent in block (https://github.com/ansible/ansible/issues/75286).
|
||||
- default callback - Ensure we compare FQCN also in lockstep logic, to ensure using the FQCN of a strategy plugin triggers the correct behavior in the default callback plugin. (https://github.com/ansible/ansible/issues/76782)
|
||||
- distribution - add EuroLinux to fact gathering (https://github.com/ansible/ansible/pull/76624).
|
||||
- distribution - detect tencentos and gather correct facts on the distro.
|
||||
- dnf - ensure releasever is passed into libdnf as string (https://github.com/ansible/ansible/issues/77010)
|
||||
- extend timeout for ansible-galaxy when communicating with the galaxy server api, and apply it to all interactions with the api
|
||||
- facts - add support for deepin distro information detection (https://github.com/ansible/ansible/issues/77286).
|
||||
- first_found - fix to allow for spaces in file names (https://github.com/ansible/ansible/issues/77136)
|
||||
- gather_facts - Fact gathering now continues even if it fails to read a file
|
||||
- gather_facts action now handles the move of base connection plugin types into collections to add/prevent subset argument correctly
|
||||
- gather_facts/setup will not fail anymore if capsh is present but not executable
|
||||
- git module fix docs and proper use of ssh wrapper script and GIT_SSH_COMMAND depending on version.
|
||||
- git module is more consistent and clearer about which ssh options are added to git calls.
|
||||
- git module no longer uses wrapper script for ssh options.
|
||||
- hacking - fix incorrect usage of deprecated fish-shell redirection operators that failed to honor ``--quiet`` flag when sourced (https://github.com/ansible/ansible/pull/77180).
|
||||
- hostname - Do not require SystemdStrategy subclasses for every distro (https://github.com/ansible/ansible/issues/76792)
|
||||
- hostname - Fix Debian strategy KeyError, use `SystemdStrategy` (https://github.com/ansible/ansible/issues/76124)
|
||||
- hostname - Update the systemd strategy in the ``hostname`` module to not interfere with NetworkManager (https://github.com/ansible/ansible/issues/76958)
|
||||
- hostname - add hostname support for openEuler distro (https://github.com/ansible/ansible/pull/76619).
|
||||
- hostname - use ``file_get_content()`` to read the file containing the host name in the ``FileStrategy.get_permanent_hostname()`` method. This prevents a ``TypeError`` from being raised when the strategy is used (https://github.com/ansible/ansible/issues/77025).
|
||||
- include_vars, properly initialize variable as there is corner case in which it can end up referenced and not defined
|
||||
- inventory - parameterize ``disable_lookups`` in ``Constructable`` (https://github.com/ansible/ansible/issues/76769).
|
||||
- inventory manager now respects --flush-cache
|
||||
- junit callback - Fix traceback during automatic fact gathering when using relative paths.
|
||||
- junit callback - Fix unicode error when handling non-ASCII task paths.
|
||||
- module_utils.common.yaml - The ``SafeLoader``, ``SafeDumper`` and ``Parser`` classes now fallback to ``object`` when ``yaml`` is not available. This fixes tracebacks when inheriting from these classes without requiring a ``HAS_YAML`` guard around class definitions.
|
||||
- parameters - handle blank values when argument is a list (https://github.com/ansible/ansible/issues/77108).
|
||||
- play_context now compensates for when a conneciton sets the default to inventory_hostname but skips adding it to the vars.
|
||||
- playbook/strategy have more informative 'attribute' based errors for playbook objects and handlers.
|
||||
- python modules (new type) will now again prefer the specific python stated in the module's shebang instead of hardcoding to /usr/bin/python.
|
||||
- replace - Always return ``rc`` to ensure return values are consistent - https://github.com/ansible/ansible/pull/71963
|
||||
- script - skip in check mode if the plugin cannot determine if a change will occur (i.e. neither `creates` or `removes` are provided).
|
||||
- service - Fixed handling of sleep arguments during service restarts on AIX. (https://github.com/ansible/ansible/issues/76877)
|
||||
- service - Fixed service restarts with arguments on AIX. (https://github.com/ansible/ansible/issues/76840)
|
||||
- service_facts module will now give more meaningful warnings when it fails to gather data.
|
||||
- set_fact/include_vars correctly handle delegation assignments within loops
|
||||
- setup - detect docker container with check for ./dockerenv or ./dockinit (https://github.com/ansible/ansible/pull/74349).
|
||||
- shell/command - only return changed as True if the task has not been skipped.
|
||||
- shell/command - only skip in check mode if the options `creates` and `removes` are both None.
|
||||
- ssh connection - properly quote controlpersist path given by user to avoid issues with spaces and other characters
|
||||
- ssh connection avoid parsing ssh cli debug lines as they can match expected output at high verbosities.
|
||||
- ssh connection now uses more correct host source as play_context can ignore loop/delegation variations.
|
||||
- sudo become plugin, fix handling of non interactive flags, previous substitution was too naive
|
||||
- systemd - check if service is alias so it gets enabled (https://github.com/ansible/ansible/issues/75538).
|
||||
- systemd - check if service is indirect so it gets enabled (https://github.com/ansible/ansible/issues/76453).
|
||||
- task_executor reverts the change to push facts into delegated vars on loop finalization as result managing code already handles this and was duplicating effort to wrong result.
|
||||
- template lookup - restore inadvertently deleted default for ``convert_data`` (https://github.com/ansible/ansible/issues/77004)
|
||||
- to_json/to_nice_json filters defaults back to unvaulting/no unsafe packing.
|
||||
- unarchive - Fix zip archive file listing that caused issues with content postprocessing (https://github.com/ansible/ansible/issues/76067).
|
||||
- unarchive - Make extraction work when the LANGUAGE environment variable is set to a non-English locale.
|
||||
- unarchive - apply ``owner`` and ``group`` permissions to top folder (https://github.com/ansible/ansible/issues/35426)
|
||||
- unarchive - include the original error when a handler cannot manage the archive (https://github.com/ansible/ansible/issues/28977).
|
||||
- unarchive - the ``io_buffer_size`` option added in 2.12 was not accepted by the module (https://github.com/ansible/ansible/pull/77271).
|
||||
- urls - Allow ``ca_path`` to point to a bundle containing multiple PEM certs (https://github.com/ansible/ansible/issues/75015)
|
||||
- urls/uri - Address case where ``HTTPError`` isn't fully initialized due to the error, and is missing certain methods and attributes (https://github.com/ansible/ansible/issues/76386)
|
||||
- user - allow ``password_expiry_min`` and ``password_expiry_min`` to be set to ``0`` (https://github.com/ansible/ansible/issues/75017)
|
||||
- user - allow password min and max to be set at the same time (https://github.com/ansible/ansible/issues/75017)
|
||||
- user - update logic to check if user exists or not in MacOS.
|
||||
- validate_argument_spec - Skip suboption validation if the top level option is an invalid type (https://github.com/ansible/ansible/issues/75612).
|
||||
- vault - Warn instead of fail for missing vault IDs if at least one valid vault secret is found.
|
||||
- winrm - Ensure ``kinit`` is run with the same ``PATH`` env var as the Ansible process
|
||||
- yum - prevent storing unnecessary cache data by running `yum makecache fast` (https://github.com/ansible/ansible/issues/76336)
|
||||
|
||||
Known Issues
|
||||
------------
|
||||
|
||||
- get_url - document ``check_mode`` correctly with unreliable changed status (https://github.com/ansible/ansible/issues/65687).
|
||||
@ -1,2 +1,746 @@
|
||||
ancestor: 2.12.0
|
||||
releases: {}
|
||||
releases:
|
||||
2.13.0b0:
|
||||
changes:
|
||||
breaking_changes:
|
||||
- Module Python Dependency - Drop support for Python 2.6 in module execution.
|
||||
- Templating - it is no longer allowed to perform arithmetic and concatenation
|
||||
operations outside of the jinja template (https://github.com/ansible/ansible/pull/75587)
|
||||
- The ``finalize`` method is no longer exposed in the globals for use in templating.
|
||||
bugfixes:
|
||||
- Add a YAML representer for ``NativeJinjaText``
|
||||
- Add a YAML representer for ``NativeJinjaUnsafeText``
|
||||
- AnsiballZ - Ensure we use the full python package in the module cache filename
|
||||
to avoid a case where ``collections:`` is used to execute a module via short
|
||||
name, where the short name duplicates another module from ``ansible.builtin``
|
||||
or another collection that was executed previously.
|
||||
- Ansible.ModuleUtils.LinkUtil - Ignore the ``LIB`` environment variable when
|
||||
loading the ``LinkUtil`` code
|
||||
- Ansible.ModuleUtils.SID - Use user principal name as is for lookup in the
|
||||
``Convert-ToSID`` function - https://github.com/ansible/ansible/issues/77316
|
||||
- Detect package manager for Amazon Linux 2022 (AL2022) as dnf
|
||||
- Ensure the correct ``environment_class`` is set on ``AnsibleJ2Template``
|
||||
- Fix ``AttributeError`` when providing password file via ``--connection-password-file``
|
||||
(https://github.com/ansible/ansible/issues/76530)
|
||||
- Fix ``end_play`` to end the current play only (https://github.com/ansible/ansible/issues/76672)
|
||||
- Fix collection filter/test plugin redirects (https://github.com/ansible/ansible/issues/77192).
|
||||
- Fix executing includes in the always section in the free strategy (https://github.com/ansible/ansible/issues/75642)
|
||||
- Fix for when templating empty template file resulted in file with string 'None'
|
||||
(https://github.com/ansible/ansible/issues/76610)
|
||||
- Fix help message for the 'ansible-galaxy collection verify' positional argument.
|
||||
The positional argument must be a collection name (https://github.com/ansible/ansible/issues/76087).
|
||||
- Fix module logging issue when using custom module on WSL2 (https://github.com/ansible/ansible/issues/76320)
|
||||
- Fix task debugger to work with ``run_once`` using ``linear`` strategy (https://github.com/ansible/ansible/issues/76049)
|
||||
- Fix traceback when installing a collection from a git repository and git is
|
||||
not installed (https://github.com/ansible/ansible/issues/77479).
|
||||
- Interpreter Discovery - Fallback to OS family if the distro is not found in
|
||||
``INTERPRETER_PYTHON_DISTRO_MAP`` (https://github.com/ansible/ansible/issues/75560)
|
||||
- Interpreter discovery - Add ``RHEL`` to ``OS_FAMILY_MAP`` for correct family
|
||||
fallback for interpreter discovery (https://github.com/ansible/ansible/issues/77368)
|
||||
- Make include_role/include_tasks work with any_errors_fatal (https://github.com/ansible/ansible/issues/50897)
|
||||
- Parser errors from within includes should not be rescueable (https://github.com/ansible/ansible/issues/73657)
|
||||
- Templating - Ensure we catch exceptions when getting ``.filters`` and ``.tests``
|
||||
attributes on their respective plugins and properly error, instead of aborting
|
||||
which results in no filters being added to the jinja2 environment
|
||||
- Trigger an undefined error when an undefined variable is detected within a
|
||||
dictionary and/or list (https://github.com/ansible/ansible/pull/75587)
|
||||
- _run_loop - Add the task name to the warning (https://github.com/ansible/ansible/issues/76011)
|
||||
- '``Templar.copy_with_new_env`` - set the ``finalize`` method of the new ``Templar``
|
||||
object for the new environment (https://github.com/ansible/ansible/issues/76379)'
|
||||
- 'add_host/group_by: fix using changed_when in a loop (https://github.com/ansible/ansible/issues/71627)'
|
||||
- ansible-config avoid showing _terms and _input when --only-changed.
|
||||
- ansible-doc - Fix ansible-doc -l ansible.builtin / ansible.legacy not returning
|
||||
anything
|
||||
- ansible-doc - ignore plugin deprecation warnings (https://github.com/ansible/ansible/issues/75671)
|
||||
- ansible-galaxy - Add galaxy_collection_skeleton/galaxy_collection_skeleton_ignore
|
||||
configuration options
|
||||
- ansible-galaxy - Fix using the '--ignore-certs' option when there is no server-specific
|
||||
configuration for the Galaxy server.
|
||||
- ansible-galaxy - installing/downloading collections with invalid versions
|
||||
in git repositories and directories now gives a formatted error message (https://github.com/ansible/ansible/issues/76425,
|
||||
https://github.com/ansible/ansible/issues/75404).
|
||||
- ansible-galaxy - when installing a role properly raise an error when inaccessible
|
||||
path is specified multiple times in roles_path (e.g. via environment variable
|
||||
and command line option) (https://github.com/ansible/ansible/issues/76316)
|
||||
- ansible-galaxy collection build - Ignore any existing ``MANIFEST.json`` and
|
||||
``FILES.json`` in the root directory when building a collection.
|
||||
- ansible-galaxy collection verify - display files/directories not included
|
||||
in the FILES.json as modified content.
|
||||
- ansible-galaxy publish - Fix warning and error detection in import messages
|
||||
to properly display them in Ansible
|
||||
- ansible-pull handle case where hostname and nodename are empty
|
||||
- ansible-test - Add default entry for Windows remotes to be used with unknown
|
||||
versions.
|
||||
- ansible-test - All virtual environments managed by ansible-test are marked
|
||||
as usable after being bootstrapped, to avoid errors caused by use of incomplete
|
||||
environments. Previously this was only done for sanity tests. Existing environments
|
||||
from previous versions of ansible-test will be recreated on demand due to
|
||||
lacking the new marker.
|
||||
- ansible-test - Automatic target requirements installation is now based on
|
||||
the target environment instead of the controller environment.
|
||||
- ansible-test - Correctly detect when running as the ``root`` user (UID 0)
|
||||
on the origin host. The result of the detection was incorrectly being inverted.
|
||||
- ansible-test - Don't fail if network cannot be disconnected (https://github.com/ansible/ansible/pull/77472)
|
||||
- ansible-test - Fix Python real prefix detection when running in a ``venv``
|
||||
virtual environment.
|
||||
- ansible-test - Fix ``windows-integration`` and ``network-integration`` when
|
||||
used with the ``--docker`` option and user-provided inventory.
|
||||
- ansible-test - Fix installation and usage of ``pyyaml`` requirement for the
|
||||
``import`` sanity test for collections.
|
||||
- ansible-test - Fix path to inventory file for ``windows-integration`` and
|
||||
``network-integration`` commands for collections.
|
||||
- ansible-test - Fix plugin loading.
|
||||
- ansible-test - Fix skipping of tests marked ``needs/python`` on the origin
|
||||
host.
|
||||
- ansible-test - Fix skipping of tests marked ``needs/root`` on the origin host.
|
||||
- ansible-test - Fix the ``import`` sanity test to work properly when Ansible's
|
||||
built-in vendoring support is in use.
|
||||
- ansible-test - Fix the ``validate-modules`` sanity test to avoid double-loading
|
||||
the collection loader and possibly failing on import of the ``packaging``
|
||||
module.
|
||||
- ansible-test - Fix traceback in ``import`` sanity test on Python 2.7 when
|
||||
``pip`` is not available.
|
||||
- ansible-test - Fix traceback in the ``validate-modules`` sanity test when
|
||||
testing an Ansible module without any callables.
|
||||
- ansible-test - Fix traceback when running from an install and delegating execution
|
||||
to a different Python interpreter.
|
||||
- ansible-test - Fix traceback when using the ``--all`` option with PowerShell
|
||||
code coverage.
|
||||
- ansible-test - Fix type hints.
|
||||
- ansible-test - Import ``yaml.cyaml.CParser`` instead of ``_yaml.CParser``
|
||||
in the ``yamllint`` sanity test.
|
||||
- ansible-test - Limit ``paramiko`` installation to versions before 2.9.0. This
|
||||
is required to maintain support for systems which do not support RSA SHA-2
|
||||
algorithms.
|
||||
- ansible-test - Pylint Deprecated Plugin - Use correct message symbols when
|
||||
date or version is not a float or str (https://github.com/ansible/ansible/issues/77085)
|
||||
- ansible-test - Relocate constants to eliminate symlink.
|
||||
- ansible-test - Replace the directory portion of out-of-tree paths in JUnit
|
||||
files from integration tests with the ``out-of-tree:`` prefix.
|
||||
- ansible-test - Sanity tests run with the ``--requirements` option for Python
|
||||
2.x now install ``virtualenv`` when it is missing or too old. Previously it
|
||||
was only installed if missing. Version 16.7.12 is now installed instead of
|
||||
the latest version.
|
||||
- ansible-test - Set the ``pytest`` option ``--rootdir`` instead of letting
|
||||
it be auto-detected.
|
||||
- ansible-test - Show an error message instead of a traceback when running outside
|
||||
of a supported directory.
|
||||
- ansible-test - Target integration test requirements are now correctly installed
|
||||
for target environments running on the controller.
|
||||
- ansible-test - The ``import`` sanity test no longer reports errors about ``packaging``
|
||||
being missing when testing collections.
|
||||
- ansible-test - Update distribution test containers to version 3.1.0.
|
||||
- ansible-test - Update help links to reference ``ansible-core`` instead of
|
||||
``ansible``.
|
||||
- ansible-test - Update unit tests to use the ``--forked`` option instead of
|
||||
the deprecated ``--boxed`` option.
|
||||
- ansible-test - Use https://ci-files.testing.ansible.com/ for instance bootstrapping
|
||||
instead of an S3 endpoint.
|
||||
- ansible-test - Use relative paths in JUnit files generated during integration
|
||||
test runs.
|
||||
- ansible-test - Use the correct variable to reference the client's SSH key
|
||||
when generating inventory.
|
||||
- ansible-test - Use the legacy collection loader for ``import`` sanity tests
|
||||
on target-only Python versions.
|
||||
- ansible-test - Virtual environments managed by ansible-test now use consistent
|
||||
versions of ``pip``, ``setuptools`` and ``wheel``. This avoids issues with
|
||||
virtual environments containing outdated or dysfunctional versions of these
|
||||
tools. The initial bootstrapping of ``pip`` is done by ansible-test from an
|
||||
HTTPS endpoint instead of creating the virtual environment with it already
|
||||
present.
|
||||
- ansible-test - fix a typo in validate-modules.
|
||||
- ansible-test - fixed support container failures (eg http-test-container) under
|
||||
podman
|
||||
- ansible-test compile sanity test - do not crash if a column could not be determined
|
||||
for an error (https://github.com/ansible/ansible/pull/77465).
|
||||
- ansible-test pslint - Fix error when encountering validation results that
|
||||
are highly nested - https://github.com/ansible/ansible/issues/74151
|
||||
- ansible-vault encrypt_string - fix ``--output`` option to correctly write
|
||||
encrypted string into given file (https://github.com/ansible/ansible/issues/75101)
|
||||
- ansible.builtin.file modification_time supports check_mode
|
||||
- ansible_facts.devices - Fix parsing of device serial number detected via sg_inq
|
||||
for rhel8 (https://github.com/ansible/ansible/issues/75420)
|
||||
- apt - fails to deploy deb file to old debian systems using python-apt < 0.8.9
|
||||
(https://github.com/ansible/ansible/issues/47277)
|
||||
- async - Improve performance of sending async callback events by never sending
|
||||
the full task through the queue (https://github.com/ansible/ansible/issues/76729)
|
||||
- catch the case that cowsay is broken which would lead to missing output
|
||||
- cleaning facts will now only warn about the variable name and not post the
|
||||
content, which can be undesireable to disclose
|
||||
- collection_loader - Implement 'find_spec' and 'exec_module' to override deprecated
|
||||
importlib methods 'find_module' and 'load_module' when applicable (https://github.com/ansible/ansible/issues/74660).
|
||||
- correctly inherit vars from parent in block (https://github.com/ansible/ansible/issues/75286).
|
||||
- default callback - Ensure we compare FQCN also in lockstep logic, to ensure
|
||||
using the FQCN of a strategy plugin triggers the correct behavior in the default
|
||||
callback plugin. (https://github.com/ansible/ansible/issues/76782)
|
||||
- distribution - add EuroLinux to fact gathering (https://github.com/ansible/ansible/pull/76624).
|
||||
- distribution - detect tencentos and gather correct facts on the distro.
|
||||
- dnf - ensure releasever is passed into libdnf as string (https://github.com/ansible/ansible/issues/77010)
|
||||
- extend timeout for ansible-galaxy when communicating with the galaxy server
|
||||
api, and apply it to all interactions with the api
|
||||
- facts - add support for deepin distro information detection (https://github.com/ansible/ansible/issues/77286).
|
||||
- first_found - fix to allow for spaces in file names (https://github.com/ansible/ansible/issues/77136)
|
||||
- gather_facts - Fact gathering now continues even if it fails to read a file
|
||||
- gather_facts action now handles the move of base connection plugin types into
|
||||
collections to add/prevent subset argument correctly
|
||||
- gather_facts/setup will not fail anymore if capsh is present but not executable
|
||||
- git module fix docs and proper use of ssh wrapper script and GIT_SSH_COMMAND
|
||||
depending on version.
|
||||
- git module is more consistent and clearer about which ssh options are added
|
||||
to git calls.
|
||||
- git module no longer uses wrapper script for ssh options.
|
||||
- hacking - fix incorrect usage of deprecated fish-shell redirection operators
|
||||
that failed to honor ``--quiet`` flag when sourced (https://github.com/ansible/ansible/pull/77180).
|
||||
- hostname - Do not require SystemdStrategy subclasses for every distro (https://github.com/ansible/ansible/issues/76792)
|
||||
- hostname - Fix Debian strategy KeyError, use `SystemdStrategy` (https://github.com/ansible/ansible/issues/76124)
|
||||
- hostname - Update the systemd strategy in the ``hostname`` module to not interfere
|
||||
with NetworkManager (https://github.com/ansible/ansible/issues/76958)
|
||||
- hostname - add hostname support for openEuler distro (https://github.com/ansible/ansible/pull/76619).
|
||||
- hostname - use ``file_get_content()`` to read the file containing the host
|
||||
name in the ``FileStrategy.get_permanent_hostname()`` method. This prevents
|
||||
a ``TypeError`` from being raised when the strategy is used (https://github.com/ansible/ansible/issues/77025).
|
||||
- include_vars, properly initialize variable as there is corner case in which
|
||||
it can end up referenced and not defined
|
||||
- inventory - parameterize ``disable_lookups`` in ``Constructable`` (https://github.com/ansible/ansible/issues/76769).
|
||||
- inventory manager now respects --flush-cache
|
||||
- junit callback - Fix traceback during automatic fact gathering when using
|
||||
relative paths.
|
||||
- junit callback - Fix unicode error when handling non-ASCII task paths.
|
||||
- module_utils.common.yaml - The ``SafeLoader``, ``SafeDumper`` and ``Parser``
|
||||
classes now fallback to ``object`` when ``yaml`` is not available. This fixes
|
||||
tracebacks when inheriting from these classes without requiring a ``HAS_YAML``
|
||||
guard around class definitions.
|
||||
- parameters - handle blank values when argument is a list (https://github.com/ansible/ansible/issues/77108).
|
||||
- play_context now compensates for when a conneciton sets the default to inventory_hostname
|
||||
but skips adding it to the vars.
|
||||
- playbook/strategy have more informative 'attribute' based errors for playbook
|
||||
objects and handlers.
|
||||
- python modules (new type) will now again prefer the specific python stated
|
||||
in the module's shebang instead of hardcoding to /usr/bin/python.
|
||||
- replace - Always return ``rc`` to ensure return values are consistent - https://github.com/ansible/ansible/pull/71963
|
||||
- script - skip in check mode if the plugin cannot determine if a change will
|
||||
occur (i.e. neither `creates` or `removes` are provided).
|
||||
- service - Fixed handling of sleep arguments during service restarts on AIX.
|
||||
(https://github.com/ansible/ansible/issues/76877)
|
||||
- service - Fixed service restarts with arguments on AIX. (https://github.com/ansible/ansible/issues/76840)
|
||||
- service_facts module will now give more meaningful warnings when it fails
|
||||
to gather data.
|
||||
- set_fact/include_vars correctly handle delegation assignments within loops
|
||||
- setup - detect docker container with check for ./dockerenv or ./dockinit (https://github.com/ansible/ansible/pull/74349).
|
||||
- shell/command - only return changed as True if the task has not been skipped.
|
||||
- shell/command - only skip in check mode if the options `creates` and `removes`
|
||||
are both None.
|
||||
- ssh connection - properly quote controlpersist path given by user to avoid
|
||||
issues with spaces and other characters
|
||||
- ssh connection avoid parsing ssh cli debug lines as they can match expected
|
||||
output at high verbosities.
|
||||
- ssh connection now uses more correct host source as play_context can ignore
|
||||
loop/delegation variations.
|
||||
- sudo become plugin, fix handling of non interactive flags, previous substitution
|
||||
was too naive
|
||||
- systemd - check if service is alias so it gets enabled (https://github.com/ansible/ansible/issues/75538).
|
||||
- systemd - check if service is indirect so it gets enabled (https://github.com/ansible/ansible/issues/76453).
|
||||
- task_executor reverts the change to push facts into delegated vars on loop
|
||||
finalization as result managing code already handles this and was duplicating
|
||||
effort to wrong result.
|
||||
- template lookup - restore inadvertently deleted default for ``convert_data``
|
||||
(https://github.com/ansible/ansible/issues/77004)
|
||||
- to_json/to_nice_json filters defaults back to unvaulting/no unsafe packing.
|
||||
- unarchive - Fix zip archive file listing that caused issues with content postprocessing
|
||||
(https://github.com/ansible/ansible/issues/76067).
|
||||
- unarchive - Make extraction work when the LANGUAGE environment variable is
|
||||
set to a non-English locale.
|
||||
- unarchive - apply ``owner`` and ``group`` permissions to top folder (https://github.com/ansible/ansible/issues/35426)
|
||||
- unarchive - include the original error when a handler cannot manage the archive
|
||||
(https://github.com/ansible/ansible/issues/28977).
|
||||
- unarchive - the ``io_buffer_size`` option added in 2.12 was not accepted by
|
||||
the module (https://github.com/ansible/ansible/pull/77271).
|
||||
- urls - Allow ``ca_path`` to point to a bundle containing multiple PEM certs
|
||||
(https://github.com/ansible/ansible/issues/75015)
|
||||
- urls/uri - Address case where ``HTTPError`` isn't fully initialized due to
|
||||
the error, and is missing certain methods and attributes (https://github.com/ansible/ansible/issues/76386)
|
||||
- user - allow ``password_expiry_min`` and ``password_expiry_min`` to be set
|
||||
to ``0`` (https://github.com/ansible/ansible/issues/75017)
|
||||
- user - allow password min and max to be set at the same time (https://github.com/ansible/ansible/issues/75017)
|
||||
- user - update logic to check if user exists or not in MacOS.
|
||||
- validate_argument_spec - Skip suboption validation if the top level option
|
||||
is an invalid type (https://github.com/ansible/ansible/issues/75612).
|
||||
- vault - Warn instead of fail for missing vault IDs if at least one valid vault
|
||||
secret is found.
|
||||
- winrm - Ensure ``kinit`` is run with the same ``PATH`` env var as the Ansible
|
||||
process
|
||||
- yum - prevent storing unnecessary cache data by running `yum makecache fast`
|
||||
(https://github.com/ansible/ansible/issues/76336)
|
||||
deprecated_features:
|
||||
- ansible-core - Remove support for Python 2.6.
|
||||
- ansible-test - Remove support for Python 2.6.
|
||||
- ssh connection plugin option scp_if_ssh in favor of ssh_transfer_method.
|
||||
known_issues:
|
||||
- get_url - document ``check_mode`` correctly with unreliable changed status
|
||||
(https://github.com/ansible/ansible/issues/65687).
|
||||
major_changes:
|
||||
- Jinja2 Controller Requirement - Jinja2 3.0.0 or newer is required for the
|
||||
control node (the machine that runs Ansible) (https://github.com/ansible/ansible/pull/75881)
|
||||
- Templating - remove ``safe_eval`` in favor of using ``NativeEnvironment``
|
||||
but utilizing ``literal_eval`` only in cases when ``safe_eval`` was used (https://github.com/ansible/ansible/pull/75587)
|
||||
minor_changes:
|
||||
- Action Plugins - Add helper method for argument spec validation, and extend
|
||||
to pause and async_wrapper
|
||||
- Added AIX root CA certs folders - enhance the TLS support in ``uri`` task
|
||||
on AIX
|
||||
- Added ``module_utils.compat.typing`` to facilitate type-hinting on all supported
|
||||
Python versions.
|
||||
- Ansible.Basic - small changes to allow use in PowerShell modules running on
|
||||
non-Windows platforms (https://github.com/ansible/ansible/pull/76924).
|
||||
- AnsibleModule.run_command() now has a toggle to allow caller to decide to
|
||||
handle exceptions from executing the command itself
|
||||
- Attach concat function to an environment class (https://github.com/ansible/ansible/pull/76282)
|
||||
- Clarify in a comment that unrolling an iterator in ``Templar._finalize`` is
|
||||
actually necessary. Also switch to using the ``_unroll_iterator`` decorator
|
||||
directly to deduplicate code in ``Templar._finalize``. (https://github.com/ansible/ansible/pull/76436)
|
||||
- Installation - modernize our python installation, to reduce dynamic code in
|
||||
setup.py, and migrate what is feasible to setup.cfg. This will enable shipping
|
||||
wheels in the future.
|
||||
- PlayIterator - introduce public methods to access ``PlayIterator._host_states``
|
||||
(https://github.com/ansible/ansible/pull/74416)
|
||||
- PlayIterator - use enums for Iterating and Failed states (https://github.com/ansible/ansible/pull/74511)
|
||||
- Reduce number of iterations through PlayIterator (https://github.com/ansible/ansible/pull/74175)
|
||||
- Remove more Python 2.x compatibility code from controller (https://github.com/ansible/ansible/pull/77320).
|
||||
- Start of moving away from using Six, Python 2 and 3 compatibility library
|
||||
(https://github.com/ansible/ansible/pull/75863)
|
||||
- The collection loader now reports a Python warning if an attempt is made to
|
||||
install the Ansible collection loader a second time. Previously this condition
|
||||
was reported using an Ansible warning.
|
||||
- '``ansible-galaxy collection [install|verify]`` - allow user-provided signature
|
||||
sources in addition to those from the Galaxy server. Each collection entry
|
||||
in a requirements file can specify a ``signatures`` key followed by a list
|
||||
of sources. Collection name(s) provided on the CLI can specify additional
|
||||
signature sources by using the ``--signatures`` CLI option. Signature sources
|
||||
should be URIs that can be opened with ``urllib.request.urlopen()``, such
|
||||
as "https://example.com/path/to/detached_signature.asc" or "file:///path/to/detached_signature.asc".
|
||||
The ``--keyring`` option must be specified if signature sources are provided.'
|
||||
- '``ansible-galaxy collection [install|verify]`` - use gpg to verify the authenticity
|
||||
of the signed ``MANIFEST.json`` with ASCII armored detached signatures provided
|
||||
by the Galaxy server. The keyring (which is not managed by ``ansible-galaxy``)
|
||||
must be provided with the ``--keyring`` option to use signature verification.
|
||||
If no ``--keyring`` is specified and the collection to ``install|verify``
|
||||
has associated detached signatures on the Galaxy server, a warning is provided.'
|
||||
- '``ansible-galaxy collection install`` - Add a global configuration to modify
|
||||
the required number of signatures that must verify the authenticity of the
|
||||
collection. By default, the number of required successful signatures is 1.
|
||||
Set this option to ``all`` to require all signatures verify the collection.
|
||||
To ensure signature verification fails if there are no valid signatures, prepend
|
||||
the value with ''+'', such as ``+all`` or ``+1``.'
|
||||
- '``ansible-galaxy collection install`` - Add a global ignore list for gpg
|
||||
signature errors. This can be used to ignore certain signatures when the number
|
||||
of required successful signatures is all. When the required number of successful
|
||||
signatures is a positive integer, the only effect this has is to display fewer
|
||||
errors to the user on failure (success is determined by having the minimum
|
||||
number of successful signatures, in which case all errors are disregarded).'
|
||||
- '``ansible-galaxy collection install`` - Add a global toggle to turn off GPG
|
||||
signature verification.'
|
||||
- '``ansible-galaxy collection install`` - Store Galaxy server metadata alongside
|
||||
installed collections for provenance. Signatures obtained from the Galaxy
|
||||
server can be used for offline verification with ``ansible-galaxy collection
|
||||
verify --offline``.'
|
||||
- ansible-console - Provide a way to customize the stdout callback
|
||||
- ansible-core modules - Remove unused Python shebangs from built-in modules.
|
||||
- ansible-doc metadata dump - add option ``--no-fail-on-errors`` which allows
|
||||
to not fail the ansible-doc invocation when errors happen during docs parsing
|
||||
or processing. Instead they are reported in the JSON result in an ``error``
|
||||
key for the affected plugins (https://github.com/ansible/ansible/pull/77035).
|
||||
- ansible-galaxy - the option to skip certificate verification now also applies
|
||||
when cloning via SCM (git/hg) (https://github.com/ansible/ansible/issues/41077)
|
||||
- ansible-test - Accept new-style Python modules without a shebang.
|
||||
- ansible-test - Add ``--version`` support to show the ansible-core version.
|
||||
- ansible-test - Add support for ``rhel/8.5`` remote instances.
|
||||
- ansible-test - Add support for remote testing of FreeBSD 12.3.
|
||||
- ansible-test - Add support for running container tests with ``podman remote``
|
||||
(https://github.com/ansible/ansible/pull/75753)
|
||||
- ansible-test - Added the ``fedora35`` test container.
|
||||
- ansible-test - Change the maximum number of open files in a test container
|
||||
from the default to ``10240``.
|
||||
- ansible-test - Declare public dependencies of ansible-core and use to limit
|
||||
unguarded imports in plugins.
|
||||
- ansible-test - Importing ``distutils`` now results in an error.
|
||||
- ansible-test - Installation of ``cryptography`` is no longer version constrained
|
||||
when ``openssl`` 1.1.0 or later is installed.
|
||||
- ansible-test - Miscellaneous code cleanup and type hint fixes.
|
||||
- ansible-test - PowerShell in the ``base`` and ``default`` containers has been
|
||||
upgraded to version 7.1.4.
|
||||
- ansible-test - Remove RHEL 8.4 remote (``rhel/8.4``) support.
|
||||
- ansible-test - Remove ``idna`` constraint.
|
||||
- ansible-test - Remove obsolete ``MAXFD`` display.
|
||||
- ansible-test - Remove obsolete constraints for Python 2.6.
|
||||
- ansible-test - Remove support for FreeBSD 12.2 remote provisioning.
|
||||
- ansible-test - Remove support for macOS 11.1 remote provisioning.
|
||||
- ansible-test - Remove support for provisioning remote AIX instances.
|
||||
- ansible-test - Remove the ``centos8`` test container since CentOS 8 will reach
|
||||
end-of-life soon.
|
||||
- ansible-test - Remove the ``fedora33`` test container since Fedora 33 will
|
||||
reach end-of-life soon.
|
||||
- ansible-test - Remove unused Python 2.x compatibility code.
|
||||
- ansible-test - Removed support for Sherlock from the Azure provisioning plugin.
|
||||
- ansible-test - Removed used ``MarkupSafe`` constraint for Python 3.5 and earlier.
|
||||
- ansible-test - Requirements for the plugin import test are now frozen.
|
||||
- ansible-test - Shellcheck in the ``base`` and ``default`` containers has been
|
||||
upgraded to version 0.7.0.
|
||||
- ansible-test - Stop early with an error if the current working directory contains
|
||||
an invalid collection namespace or name.
|
||||
- ansible-test - The ``--help`` option is now available when an unsupported
|
||||
cwd is in use.
|
||||
- ansible-test - The ``--help`` output now shows the same instructions about
|
||||
cwd as would be shown in error messages if the cwd is unsupported.
|
||||
- ansible-test - The ``pip`` and ``wheel`` packages are removed from all sanity
|
||||
test virtual environments after installation completes to reduce their size.
|
||||
Previously they were only removed from the environments used for the ``import``
|
||||
sanity test.
|
||||
- ansible-test - The explanation about cwd usage has been improved to explain
|
||||
more clearly what is required.
|
||||
- ansible-test - The hash for all managed sanity test virtual environments has
|
||||
changed. Containers that include ``ansible-test sanity --prime-venvs`` will
|
||||
need to be rebuilt to continue using primed virtual environments.
|
||||
- ansible-test - Update ``base`` container to version 2.1.0.
|
||||
- ansible-test - Update ``base`` container to version 2.2.0.
|
||||
- ansible-test - Update ``default`` containers to version 5.2.0.
|
||||
- ansible-test - Update ``default`` containers to version 5.4.0.
|
||||
- ansible-test - Update ``default`` containers to version 5.5.0.
|
||||
- ansible-test - Update ``default`` containers to version 5.6.2.
|
||||
- ansible-test - Update ``default`` containers to version 5.7.0.
|
||||
- ansible-test - Update ``default`` containers to version 5.8.0.
|
||||
- ansible-test - Update ``pip`` used to bootstrap remote FreeBSD instances from
|
||||
version 20.3.4 to 21.3.1.
|
||||
- ansible-test - Update sanity test requirements.
|
||||
- ansible-test - Update the NIOS test plugin container to version 1.4.0.
|
||||
- ansible-test - Update the ``alpine`` container to version 3.3.0. This updates
|
||||
the base image from 3.14.2 to 3.15.0, which includes support for installing
|
||||
binary wheels using pip.
|
||||
- ansible-test - Update the ``base`` and ``default`` containers from Python
|
||||
3.10.0rc2 to 3.10.0.
|
||||
- ansible-test - Update the ``base`` and ``default`` containers from a Ubuntu
|
||||
18.04 to Ubuntu 20.04 base image.
|
||||
- ansible-test - Update the ``default`` containers to version 5.1.0.
|
||||
- ansible-test - Update the ``galaxy`` test plugin to get its container from
|
||||
a copy on quay.io.
|
||||
- ansible-test - Update the ``openshift`` test plugin to get its container from
|
||||
a copy on quay.io.
|
||||
- ansible-test - Use Python 3.10 as the default Python version for the ``base``
|
||||
and ``default`` containers.
|
||||
- ansible-test - add macOS 12.0 as a remote target (https://github.com/ansible/ansible/pull/76328)
|
||||
- ansible-test - handle JSON decode error gracefully in podman environment.
|
||||
- ansible-test pslint - Added the `AvoidLongLines <https://github.com/PowerShell/PSScriptAnalyzer/blob/master/docs/Rules/AvoidLongLines.md>`_
|
||||
rule set to a length of 160.
|
||||
- ansible-test pslint - Added the `PlaceCloseBrace <https://github.com/PowerShell/PSScriptAnalyzer/blob/master/docs/Rules/PlaceCloseBrace.md>`_
|
||||
rule set to enforce close braces on a newline.
|
||||
- ansible-test pslint - Added the `PlaceOpenBrace <https://github.com/PowerShell/PSScriptAnalyzer/blob/master/docs/Rules/PlaceOpenBrace.md>`_
|
||||
rule set to enforce open braces on the same line and a subsequent newline.
|
||||
- ansible-test pslint - Added the `UseConsistentIndentation <https://github.com/PowerShell/PSScriptAnalyzer/blob/master/docs/Rules/UseConsistentIndentation.md>`_
|
||||
rule to enforce indentation is done with 4 spaces.
|
||||
- ansible-test pslint - Added the `UseConsistentWhitespace <https://github.com/PowerShell/PSScriptAnalyzer/blob/master/docs/Rules/UseConsistentWhitespace.md>`_
|
||||
rule to enforce whitespace consistency in PowerShell.
|
||||
- ansible-test pslint - Updated ``PowerShellScriptAnalyzer`` to 1.20.0
|
||||
- ansible-test sanity validate-modules - the validate-modules sanity test now
|
||||
also checks the documentation of documentable plugin types (https://github.com/ansible/ansible/pull/71734).
|
||||
- ansible-test validate-modules sanity test - add more schema checks to improve
|
||||
quality of plugin documentation (https://github.com/ansible/ansible/pull/77268).
|
||||
- ansible-test validate_modules - allow ``choices`` for return values (https://github.com/ansible/ansible/pull/76009).
|
||||
- apt - Add support for using ">=" in package version number matching.
|
||||
- apt - Adds APT option ``--allow-change-held-packages`` as module parameter
|
||||
``allow_change_held_packages`` to allow APT up- or downgrading a package which
|
||||
is on APTs hold list (https://github.com/ansible/ansible/issues/65325)
|
||||
- auto inventory plugin will now give plugin loading information on verbose
|
||||
output
|
||||
- callbacks - Add result serialization format options to ``_dump_results`` allowing
|
||||
plugins such as the ``default`` callback to emit ``YAML`` serialized task
|
||||
results in addition to ``JSON``
|
||||
- dnf - add more specific error message for GPG validation (https://github.com/ansible/ansible/issues/76192)
|
||||
- env lookup, add default option
|
||||
- facts - report prefix length for IPv4 addresses in Linux network facts.
|
||||
- get_parsable_locale now logs result when in debug mode.
|
||||
- git - display the destination directory path in error msg when local_mods
|
||||
detects local modifications conflict so that users see the exact location
|
||||
- iptables - add the ``chain_management`` parameter that controls iptables chain
|
||||
creation and deletion
|
||||
- jinja2_native - keep same behavior on Python 3.10.
|
||||
- junit callback - Add support for replacing the directory portion of out-of-tree
|
||||
relative task paths with a placeholder.
|
||||
- k8s - scenario guides for kubernetes migrated to ``kubernetes.core`` collection.
|
||||
- module_utils.distro - Add missing ``typing`` import from original code.
|
||||
- package_facts - add pkg_info support for OpenBSD and NetBSD (https://github.com/ansible/ansible/pull/76580)
|
||||
- services_facts - Add support for openrc (https://github.com/ansible/ansible/pull/76373).
|
||||
- setting DEFAULT_FACT_PATH is being deprecated in favor of the generic module_defaults
|
||||
keyword
|
||||
- uri - Avoid reading the response body when not needed
|
||||
- uri - Eliminate multiple requests to determine the final URL for file naming
|
||||
with ``dest``
|
||||
- validate-modules - do some basic validation on the ``M(...)``, ``U(...)``,
|
||||
``L(..., ...)`` and ``R(..., ...)`` documentation markups (https://github.com/ansible/ansible/pull/76262).
|
||||
- vmware - migrated vmware scenario guides to `community.vmware` repo.
|
||||
- yum, dnf - add sslverify option to temporarily disable certificate validation
|
||||
for a repository
|
||||
release_summary: '| Release Date: 2022-04-11
|
||||
|
||||
| `Porting Guide <https://docs.ansible.com/ansible/devel/porting_guides.html>`__
|
||||
|
||||
'
|
||||
removed_features:
|
||||
- Remove deprecated ``Templar.set_available_variables()`` method (https://github.com/ansible/ansible/issues/75828)
|
||||
- cli - remove deprecated ability to set verbosity before the sub-command (https://github.com/ansible/ansible/issues/75823)
|
||||
- copy - remove deprecated ``thirsty`` alias (https://github.com/ansible/ansible/issues/75824)
|
||||
- psrp - Removed fallback on ``put_file`` with older ``pypsrp`` versions. Users
|
||||
must have at least ``pypsrp>=0.4.0``.
|
||||
- url_argument_spec - remove deprecated ``thirsty`` alias for ``get_url`` and
|
||||
``uri`` modules (https://github.com/ansible/ansible/issues/75825, https://github.com/ansible/ansible/issues/75826)
|
||||
security_fixes:
|
||||
- Do not include params in exception when a call to ``set_options`` fails. Additionally,
|
||||
block the exception that is returned from being displayed to stdout. (CVE-2021-3620)
|
||||
codename: Nobody's Fault but Mine
|
||||
fragments:
|
||||
- ' 75876-fix-parsing-of-device-serial-number-for-rhel-8.yaml'
|
||||
- 47277-fails-to-deploy-deb-when-has-no-architecture-attribute.yml
|
||||
- 50771-uri-improvements.yml
|
||||
- 50897-include_role-any_errors_fatal.yaml
|
||||
- 67616-galaxy-scm-cloning-ignore-certs.yml
|
||||
- 69776-add-aix-root-ca-certs-paths.yml
|
||||
- 71627-add_host-group_by-fix-changed_when-in-loop.yml
|
||||
- 71734-validate-plugins.yml
|
||||
- 72405-git-module-local_mods-show-conflict-destination-directory.yml
|
||||
- 72592-catch-broken-cowsay.yaml
|
||||
- 73024-unarchive-apply-permissions-top-folder.yml
|
||||
- 73629_allow-change-held-packages.yml
|
||||
- 73657-include-parser-error-fail.yml
|
||||
- 74127-bad-filter-2.yml
|
||||
- 74349-improve-docker-detection.yml
|
||||
- 74416-PlayIterator-_host_states-setters.yml
|
||||
- 74511-PlayIterator-states-enums.yml
|
||||
- 75002-apt_min_version.yml
|
||||
- 75015-ca-path-bundle.yml
|
||||
- 75017-user-password-expiry.yml
|
||||
- 75101-ansible-vault-encrypt_string-output-file.yml
|
||||
- 75538-systemd-alias-check.yml
|
||||
- 75540-warn-invalid-configured-vault-secret-files.yaml
|
||||
- 75560-interp-discovery-family-fallback.yml
|
||||
- 75635-fix-role-argspec-suboption-validation.yml
|
||||
- 75642-free-strat-fix-executing-includes.yml
|
||||
- 75671-ansible-doc-ignore-deprecations.yml
|
||||
- 75823-cli-remove-deprecated-verbosity-before-sub-cmd.yml
|
||||
- 75824-copy-remove-deprecated-thirsty-alias.yml
|
||||
- 75825-75826-get_url-uri-remove-deprecated-thirsty-alias.yml
|
||||
- 75828-remove-deprecated-set_available_variables.yml
|
||||
- 75845-ansible-galaxy-support-collection-skeleton.yml
|
||||
- 75863-start-move-away-six.yml
|
||||
- 75881-jinja2-3-min.yml
|
||||
- 76009-validate-modules-choices-return-value.yml
|
||||
- 76011-loop-variable-in-use-warning.yml
|
||||
- 76049-task-debugger-run_once.yml
|
||||
- 76069-fix-unarchive-file-listing-in-zip.yaml
|
||||
- 76108-fix-ansible-galaxy-collection-verify-help.yaml
|
||||
- 76124-hostname-debianstrategy.yml
|
||||
- 76192-dnf-specific-gpg-error.yml
|
||||
- 76225-update-collection-loader-for-python3.yaml
|
||||
- 76235-fix-ansible-doc-builtin-legacy.yml
|
||||
- 76262-validate-modules-validate-markup.yml
|
||||
- 76316-galaxy-install-role-inaccessible-dir-fix.yml
|
||||
- 76336-yum-makecache-fast.yml
|
||||
- 76343-tencentos-dnf.yml
|
||||
- 76353-fix-check-mode-skipping.yaml
|
||||
- 76356-yumdnf-sslverify.yml
|
||||
- 76365-unarchive-include-stderr-in-error-message.yml
|
||||
- 76373-add-openrc-support-to-service_facts.yaml
|
||||
- 76375-fix-module-logging-WSL2.yml
|
||||
- 76378-iptables-chain-management.yml
|
||||
- 76379-set-finalize-on-new-env.yml
|
||||
- 76386-httperror-no-fp.yml
|
||||
- 76433-get_url-document-check_mode.yml
|
||||
- 76453-indirect-systemd-status.yml
|
||||
- 76530-connection-password-file-tb-fix.yml
|
||||
- 76542-fix-unarchive-on-nenglish-locales.yml
|
||||
- 76579-fix-ansible-galaxy-collection-version-error.yml
|
||||
- 76580-add-pkg_info-support-to-package_facts.yml
|
||||
- 76610-empty-template-none.yml
|
||||
- 76672-fix-end_play-multiple_plays.yml
|
||||
- 76681-ansible-galaxy-add-gpg-signature-verification.yaml
|
||||
- 76690-fix-ansible-galaxy-collection-verify-modified-content.yaml
|
||||
- 76729-async-callback-perf.yml
|
||||
- 76735-ansible-galaxy-fix-ignore-certs.yaml
|
||||
- 76751-facts-check-datafile-before-close.yml
|
||||
- 76769-inventory-constructable-disable-lookups.yml
|
||||
- 76782-fqcn-compare-lockstep-strategies.yml
|
||||
- 76792-hostname-all-systemd.yml
|
||||
- 76840-added-restart-to-the-argument-condition-for-AIX.yml
|
||||
- 76877-added-sleep-to-the-service-restart-for-AIX.yml
|
||||
- 76924-powershell-ansible.basic-support-non-windows.yml
|
||||
- 76958-hostname-systemd-nm.yaml
|
||||
- 77004-restore-missing-default.yml
|
||||
- 77010-dnf-ensure-releasever-string.yml
|
||||
- 77035-ansible-doc-metadata-dump-errors.yml
|
||||
- 77050-add-pkg-mgr-support-for-al2022.yaml
|
||||
- 77074-hostname-fix-typeerror-in-filestrategy.yml
|
||||
- 77086-correct-pylint-symbols.yml
|
||||
- 77108_params_blank.yml
|
||||
- 77136-first_found-spaces-in-names.yml
|
||||
- 77180-fix-fish-env-setup-script.yml
|
||||
- 77193-linux-networking-facts-Provide-IPv4-prefix.yml
|
||||
- 77210-fix-collection-filter-test-redirects.yml
|
||||
- 77268-validate-plugins.yml
|
||||
- 77271-unarchive.yml
|
||||
- 77275-add-support-for-deepin-distro-info-detection.yaml
|
||||
- 77320-python-2.yml
|
||||
- 77368-rhel-os-family-compat.yaml
|
||||
- 77465-ansible-test-compile-crash.yml
|
||||
- 77472-ansible-test-network-disconnect-warning.yml
|
||||
- 77493-ansible-galaxy-find-git-executable-before-using.yaml
|
||||
- ModuleUtils.SID-long-username.yml
|
||||
- action-plugin-arg-spec.yml
|
||||
- ansible-console-callback.yaml
|
||||
- ansible-core-python-2.6.yaml
|
||||
- ansible-module-shebangs.yml
|
||||
- ansible-test-alpine3-update.yaml
|
||||
- ansible-test-azure-sherlock.yml
|
||||
- ansible-test-bootstrap-pip.yml
|
||||
- ansible-test-ci-files.yaml
|
||||
- ansible-test-code-cleanup.yml
|
||||
- ansible-test-collection-identifier.yml
|
||||
- ansible-test-constraints-cleanup.yaml
|
||||
- ansible-test-constraints.yaml
|
||||
- ansible-test-container-images.yml
|
||||
- ansible-test-container-removal.yml
|
||||
- ansible-test-default-base-containers-base-update.yaml
|
||||
- ansible-test-default-base-containers-python-3.10.yaml
|
||||
- ansible-test-default-container-update-5.2.0.yaml
|
||||
- ansible-test-default-container-update-5.4.0.yaml
|
||||
- ansible-test-default-container-update-5.5.0.yaml
|
||||
- ansible-test-default-container-update-5.6.2.yaml
|
||||
- ansible-test-default-container-update-5.7.0.yaml
|
||||
- ansible-test-default-container-update-5.8.0.yaml
|
||||
- ansible-test-default-container-update.yaml
|
||||
- ansible-test-delegation-inventory.yaml
|
||||
- ansible-test-delegation-pythonpath.yml
|
||||
- ansible-test-distro-containers-3.1.0.yaml
|
||||
- ansible-test-docker-ulimit.yml
|
||||
- ansible-test-fedora35.yml
|
||||
- ansible-test-fix-type-hints.yml
|
||||
- ansible-test-fix-typo-validate-modules.yaml
|
||||
- ansible-test-freebsd-12.3.yaml
|
||||
- ansible-test-help-cwd.yml
|
||||
- ansible-test-import-collections.yml
|
||||
- ansible-test-import-distutils.yaml
|
||||
- ansible-test-inventory-path.yaml
|
||||
- ansible-test-inventory-ssh-key.yml
|
||||
- ansible-test-junit-relative-paths.yml
|
||||
- ansible-test-links.yml
|
||||
- ansible-test-managed-venv.yml
|
||||
- ansible-test-maxfd.yaml
|
||||
- ansible-test-nios-container.yml
|
||||
- ansible-test-paramiko-constraint.yaml
|
||||
- ansible-test-plugin-loading.yml
|
||||
- ansible-test-podman-remote.yaml
|
||||
- ansible-test-podman-support-containers.yaml
|
||||
- ansible-test-powershell-coverage-all.yaml
|
||||
- ansible-test-pyopenssl.yaml
|
||||
- ansible-test-pytest-forked.yml
|
||||
- ansible-test-pytest-rootdir.yml
|
||||
- ansible-test-python-2.6.yaml
|
||||
- ansible-test-relocate-constants.yaml
|
||||
- ansible-test-remote-cleanup.yaml
|
||||
- ansible-test-remove-aix-provisioning.yaml
|
||||
- ansible-test-requirements-target.yaml
|
||||
- ansible-test-rhel-8.4.yml
|
||||
- ansible-test-rhel85.yaml
|
||||
- ansible-test-sanity-import-loader.yml
|
||||
- ansible-test-sanity-import-no-pip.yml
|
||||
- ansible-test-sanity-import.yml
|
||||
- ansible-test-sanity-requirements-update.yaml
|
||||
- ansible-test-sanity-vendoring.yml
|
||||
- ansible-test-target-filter.yml
|
||||
- ansible-test-unsupported-directory-traceback.yaml
|
||||
- ansible-test-validate-modules-collection-loader.yml
|
||||
- ansible-test-validate-modules-no-callable.yml
|
||||
- ansible-test-venv-real-prefix.yaml
|
||||
- ansible-test-windows-default.yaml
|
||||
- ansible-test-yaml-import.yaml
|
||||
- ansible_galaxy_timeout.yml
|
||||
- ansible_test.yml
|
||||
- auto_squeal.yml
|
||||
- avoid-set_options-leak.yaml
|
||||
- clarify-unroll.yml
|
||||
- clean_facts_values.yml
|
||||
- compat-typing.yml
|
||||
- config_fix_terms.yml
|
||||
- default-callback-result-format.yml
|
||||
- deprecate_default_fact_path_setting.yml
|
||||
- deprecate_scp_if_ssh.yml
|
||||
- distro-module_utils-typing.yml
|
||||
- drop-target-2.6-support.yml
|
||||
- environment-concat.yml
|
||||
- evn_default.yml
|
||||
- file_modification_times_support_check_mode.yml
|
||||
- finalize-not-in-globals.yml
|
||||
- fix_block_var_inh.yml
|
||||
- fix_fax_delegation_loops.yml
|
||||
- fix_sudo_flag_mangling.yml
|
||||
- fqn-module-cache.yml
|
||||
- galaxy-build-files-ignore.yml
|
||||
- galaxy-import-level-fix.yml
|
||||
- gather_facts_collections.yml
|
||||
- git_fixes.yml
|
||||
- handle_connection_cornercase.yml
|
||||
- include_vars_failed.yml
|
||||
- inventory_manager_flush_cache.yml
|
||||
- jinja2_native-literal_eval-py310.yml
|
||||
- json_filter_fix.yml
|
||||
- junit-callback-task-path-unicode.yml
|
||||
- log_locale_selection_results.yml
|
||||
- macos12-ci-image.yml
|
||||
- migrated_k8s_scenario_guides.yml
|
||||
- modernize-install.yaml
|
||||
- module_utils-yaml-fix.yml
|
||||
- more_targeted_attribute_errors.yml
|
||||
- nativejinjatext-yaml-representer.yml
|
||||
- nativejinjaunsafetext-yaml-representer.yml
|
||||
- openEuler_hostname.yml
|
||||
- pslint-sanity-warning.yml
|
||||
- psrp-put_file-dep.yaml
|
||||
- pull_fix_limit.yml
|
||||
- pwsh-pssa-update.yml
|
||||
- reduce-playiterator-iterations.yml
|
||||
- replace-rc-return-values.yml
|
||||
- restore_python_shebang_adherence.yml
|
||||
- runc_command_exception_toggle.yml
|
||||
- service_facts_warnings.yml
|
||||
- set_fact_delegation.yml
|
||||
- ssh_debug_noparse.yml
|
||||
- ssh_quote_cp.yml
|
||||
- ssh_use_right_host.yml
|
||||
- support_eurolinux.yml
|
||||
- templar-correct-environment_class-template.yml
|
||||
- templating-safe-eval-replaced-native_environment.yml
|
||||
- user_mac.yaml
|
||||
- v2.13.0-initial-commit.yaml
|
||||
- v2.13.0b0_summary.yaml
|
||||
- vmware_sceanrio.yml
|
||||
- win_LinkUtil-ignore-LIB.yml
|
||||
- winrm-kinit-path.yml
|
||||
release_date: '2022-04-11'
|
||||
2.13.0b1:
|
||||
changes:
|
||||
bugfixes:
|
||||
- ansible - Exclude Python 2.6 from Python interpreter discovery.
|
||||
- arg_spec - Fix incorrect ``no_log`` warning when a parameter alias is used
|
||||
(https://github.com/ansible/ansible/pull/77576)
|
||||
- variablemanager, more efficient read of vars files
|
||||
minor_changes:
|
||||
- ansible-test - Update ``default`` containers to version 5.9.0.
|
||||
release_summary: '| Release Date: 2022-04-25
|
||||
|
||||
| `Porting Guide <https://docs.ansible.com/ansible/devel/porting_guides.html>`__
|
||||
|
||||
'
|
||||
codename: Nobody's Fault but Mine
|
||||
fragments:
|
||||
- 77576-arg_spec-no_log-aliases.yml
|
||||
- ansible-test-default-container-update-5.9.0.yaml
|
||||
- python-2.6-discovery.yml
|
||||
- v2.13.0b1_summary.yaml
|
||||
- vm_more_efficient.yml
|
||||
release_date: '2022-04-25'
|
||||
|
||||
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- "ansible-test compile sanity test - do not crash if a column could not be determined for an error (https://github.com/ansible/ansible/pull/77465)."
|
||||
@ -0,0 +1,3 @@
|
||||
bugfixes:
|
||||
- ansible-test - Don't fail if network cannot be disconnected
|
||||
(https://github.com/ansible/ansible/pull/77472)
|
||||
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- Fix traceback when installing a collection from a git repository and git is not installed (https://github.com/ansible/ansible/issues/77479).
|
||||
2
changelogs/fragments/77576-arg_spec-no_log-aliases.yml
Normal file
2
changelogs/fragments/77576-arg_spec-no_log-aliases.yml
Normal file
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- arg_spec - Fix incorrect ``no_log`` warning when a parameter alias is used (https://github.com/ansible/ansible/pull/77576)
|
||||
@ -0,0 +1,2 @@
|
||||
minor_changes:
|
||||
- ansible-test - Update ``default`` containers to version 5.9.0.
|
||||
5
changelogs/fragments/ansible-test-target-filter.yml
Normal file
5
changelogs/fragments/ansible-test-target-filter.yml
Normal file
@ -0,0 +1,5 @@
|
||||
bugfixes:
|
||||
- ansible-test - Correctly detect when running as the ``root`` user (UID 0) on the origin host.
|
||||
The result of the detection was incorrectly being inverted.
|
||||
- ansible-test - Fix skipping of tests marked ``needs/root`` on the origin host.
|
||||
- ansible-test - Fix skipping of tests marked ``needs/python`` on the origin host.
|
||||
@ -1,3 +1,4 @@
|
||||
bugfixes:
|
||||
- git module no longer uses wrapper script for ssh options.
|
||||
- git module is more consistent and clearer about which ssh options are added to git calls.
|
||||
- git module fix docs and proper use of ssh wrapper script and GIT_SSH_COMMAND depending on version.
|
||||
|
||||
2
changelogs/fragments/python-2.6-discovery.yml
Normal file
2
changelogs/fragments/python-2.6-discovery.yml
Normal file
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- ansible - Exclude Python 2.6 from Python interpreter discovery.
|
||||
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- Ensure the correct ``environment_class`` is set on ``AnsibleJ2Template``
|
||||
3
changelogs/fragments/v2.13.0b0_summary.yaml
Normal file
3
changelogs/fragments/v2.13.0b0_summary.yaml
Normal file
@ -0,0 +1,3 @@
|
||||
release_summary: |
|
||||
| Release Date: 2022-04-11
|
||||
| `Porting Guide <https://docs.ansible.com/ansible/devel/porting_guides.html>`__
|
||||
3
changelogs/fragments/v2.13.0b1_summary.yaml
Normal file
3
changelogs/fragments/v2.13.0b1_summary.yaml
Normal file
@ -0,0 +1,3 @@
|
||||
release_summary: |
|
||||
| Release Date: 2022-04-25
|
||||
| `Porting Guide <https://docs.ansible.com/ansible/devel/porting_guides.html>`__
|
||||
2
changelogs/fragments/vm_more_efficient.yml
Normal file
2
changelogs/fragments/vm_more_efficient.yml
Normal file
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- variablemanager, more efficient read of vars files
|
||||
2
changelogs/fragments/winrm-kinit-path.yml
Normal file
2
changelogs/fragments/winrm-kinit-path.yml
Normal file
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- winrm - Ensure ``kinit`` is run with the same ``PATH`` env var as the Ansible process
|
||||
@ -4,7 +4,7 @@
|
||||
# test/sanity/code-smell/docs-build.requirements.txt
|
||||
# test/sanity/code-smell/rstcheck.requirements.txt
|
||||
|
||||
antsibull == 0.42.0
|
||||
antsibull-docs == 1.0.0
|
||||
# sphinx 4.2.0 requires docutils < 0.18
|
||||
docutils == 0.17.1
|
||||
jinja2 == 3.0.3
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
# if you want known good versions of these dependencies
|
||||
# use known_good_reqs.txt instead
|
||||
|
||||
antsibull >= 0.42.0
|
||||
antsibull-docs >= 1.0.0, < 2.0.0
|
||||
docutils
|
||||
jinja2
|
||||
pygments >= 2.10.0
|
||||
|
||||
@ -107,18 +107,18 @@ Covering modules / new features
|
||||
|
||||
When covering a module, cover all its options separately and their meaningful combinations. Every possible use of the module should be tested against:
|
||||
|
||||
- Idempotency (Does rerunning a task report no changes?)
|
||||
- Check-mode (Does dry-running a task behave the same as a real run? Does it not make any changes?)
|
||||
- Return values (Does the module return values consistently under different conditions?)
|
||||
- Idempotency - Does rerunning a task report no changes?
|
||||
- Check-mode - Does dry-running a task behave the same as a real run? Does it not make any changes?
|
||||
- Return values - Does the module return values consistently under different conditions?
|
||||
|
||||
Each test action has to be tested at least the following times:
|
||||
|
||||
- Perform an action in check-mode if supported (this should indicate a change).
|
||||
- Perform an action in check-mode if supported. This should indicate a change.
|
||||
- Check with another module that the changes have ``not`` been actually made.
|
||||
- Perform the action for real (this should indicate a change).
|
||||
- Perform the action for real. This should indicate a change.
|
||||
- Check with another module that the changes have been actually made.
|
||||
- Perform the action again in check-mode (this should indicate ``no`` change).
|
||||
- Perform the action again for real (this should indicate ``no`` change).
|
||||
- Perform the action again in check-mode. This should indicate ``no`` change.
|
||||
- Perform the action again for real. This should indicate ``no`` change.
|
||||
|
||||
To check a task:
|
||||
|
||||
@ -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 <ansible_collections.ansible.builtin.stat_module>` 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: yes`` 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: yes`` option and check the returned message with the ``assert`` module.
|
||||
|
||||
Example:
|
||||
|
||||
@ -229,7 +229,7 @@ That is enough for our very basic example.
|
||||
|
||||
In the first task, we run the ``postgresql_info`` module to fetch information from the database we installed and launched with the ``setup_postgresql_db`` target. We are saving the values returned by the module into the ``result`` variable.
|
||||
|
||||
In the second task, we check the ``result`` variable (what the first task returned) with the ``assert`` module. We expect that, among other things, the result has the version and reports that the system state has not been changed.
|
||||
In the second task, we check the ``result`` variable, which is what the first task returned, with the ``assert`` module. We expect that, among other things, the result has the version and reports that the system state has not been changed.
|
||||
|
||||
13. Run the tests in the Ubuntu 20.04 docker container:
|
||||
|
||||
|
||||
@ -0,0 +1,319 @@
|
||||
.. _collection_release_with_branches:
|
||||
|
||||
Releasing collections with release branches
|
||||
============================================
|
||||
|
||||
Collections MUST follow the `semantic versioning <https://semver.org/>`_ rules. See :ref:`releasing_collections` for high-level details.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
||||
|
||||
Release planning and announcement
|
||||
----------------------------------
|
||||
|
||||
#. Announce your intention to release the collection in a corresponding pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel <https://docs.ansible.com/ansible/devel/community/communication.html#real-time-chat>`_. Repeat the announcement in any other dedicated channels if they exist.
|
||||
|
||||
#. Ensure all the other repository maintainers are informed about the time of the following release.
|
||||
|
||||
|
||||
Releasing major collection versions
|
||||
-------------------------------------
|
||||
|
||||
The new version is assumed to be ``X.0.0``.
|
||||
|
||||
1. If you are going to release the ``community.general`` and ``community.network`` collections, create new ``backport-X`` and ``needs_backport_to_stable_X`` labels in the corresponding repositories. Copy the styles and descriptions from the corresponding existing labels.
|
||||
|
||||
2. Ensure you are in a default branch in your local fork. These examples use ``main``.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git status
|
||||
git checkout main # if needed
|
||||
|
||||
|
||||
3. Update your local fork:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git pull --rebase upstream main
|
||||
|
||||
|
||||
Creating the release branch
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
1. Create a branch ``stable-X``. Replace ``X`` with a correct number and push it to the **upstream** repository, NOT to the ``origin``.:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git branch stable-X main
|
||||
git push upstream stable-X
|
||||
|
||||
|
||||
2. Create and checkout to another branch from the ``main`` branch:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git checkout -b update_repo
|
||||
|
||||
|
||||
3. Update the version in ``galaxy.yml`` in the branch to the next **expected** version, for example, ``X.1.0``.
|
||||
|
||||
|
||||
Creating the changelogs
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
1. Replace ``changelogs/changelog.yml`` with:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
ancestor: X.0.0
|
||||
releases: {}
|
||||
|
||||
|
||||
2. Remove all changelog fragments from ``changelogs/fragments/``. Removing the changelog fragments ensures that every major release has a changelog describing changes since the last major release.
|
||||
|
||||
3. Add and commit all the changes made. Push the branch to the ``origin`` repository.
|
||||
|
||||
4. Create a pull request in the collection repository. If CI tests pass, merge the pull request since the ``main`` branch is expecting changes for the next minor/major versions
|
||||
|
||||
5. Switch to the ``stable-X`` branch.
|
||||
|
||||
6. In the ``stable-X`` branch, ensure that ``galaxy.yml`` contains the correct version number ``X.0.0``. If not, update it.
|
||||
|
||||
7. In the ``stable-X`` branch, add a changelog fragment ``changelogs/fragments/X.0.0.yml`` with the content:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
release_summary: |-
|
||||
Write some text here that should appear as the release summary for this version.
|
||||
The format is reStructuredText, but not a list as for regular changelog fragments.
|
||||
This text will be inserted into the changelog.
|
||||
|
||||
For example:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
release_summary: This is release 2.0.0 of ``community.foo``, released on YYYY-MM-DD.
|
||||
|
||||
|
||||
8. In the ``stable-X`` branch, generate the changelogs:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
antsibull-changelog release --cummulative-release
|
||||
|
||||
|
||||
9. In the ``stable-X`` branch, verify that the ``CHANGELOG.rst`` looks as expected.
|
||||
|
||||
10. In the ``stable-X`` branch, update ``README.md`` so that the changelog link points to ``/tree/stable-X/`` and no longer to ``/tree/main/``, and change badges respectively, for example, in case of AZP, add ``?branchName=stable-X`` to the AZP CI badge (https://dev.azure.com/ansible/community.xxx/_apis/build/status/CI?branchName=stable-X).
|
||||
|
||||
11. In the ``stable-X`` branch, add, commit, and push changes to ``README.md``, ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/archived fragments to the **upstream** repository, NOT to the ``origin``.
|
||||
|
||||
|
||||
Publishing the collection
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
1. In the ``stable-X`` branch, add an annotated tag to the last commit with the collection version ``X.0.0``. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy <https://galaxy.ansible.com/>`_.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git tag -n # see current tags and their comments
|
||||
git tag -a NEW_VERSION -m "comment here" # the comment can be, for example, "community.foo: 2.0.0"
|
||||
git push upstream NEW_VERSION
|
||||
|
||||
|
||||
2. Wait until the new version is published on the collection's `Ansible Galaxy <https://galaxy.ansible.com/>`_ page. It will appear in a list of tarballs available to download.
|
||||
|
||||
3. Add a GitHub release for the new tag. The title should be the version and content, such as - ``See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes``.
|
||||
|
||||
|
||||
4. Announce the release through the `Bullhorn Newsletter <https://github.com/ansible/community/wiki/News#the-bullhorn>`_.
|
||||
|
||||
5. Announce the release in the pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/Libera.Chat IRC channel <https://docs.ansible.com/ansible/devel/community/communication.html#real-time-chat>`_.
|
||||
|
||||
6. In the ``stable-X`` branch, update the version in ``galaxy.yml`` to the next **expected** version, for example, ``X.1.0``. Add, commit and push to the **upstream** repository.
|
||||
|
||||
|
||||
Releasing minor collection versions
|
||||
-------------------------------------
|
||||
|
||||
The new version is assumed to be ``X.Y.0``. All changes that should go into it are expected to be previously backported from the default branch to the ``stable-X`` branch.
|
||||
|
||||
Creating the changelogs
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
1. In the ``stable-X`` branch, make sure that ``galaxy.yml`` contains the correct version number ``X.Y.0``. If not, update it.
|
||||
|
||||
2. In the ``stable-X`` branch, add a changelog fragment ``changelogs/fragments/X.Y.0.yml`` with content:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
release_summary: |-
|
||||
Write some text here that should appear as the release summary for this version.
|
||||
The format is reStructuredText, but not a list as for regular changelog fragments.
|
||||
This text will be inserted into the changelog.
|
||||
|
||||
|
||||
3. In the ``stable-X`` branch, run:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
antsibull-changelog release
|
||||
|
||||
|
||||
4. In the ``stable-X`` branch, verify that ``CHANGELOG.rst`` looks as expected.
|
||||
|
||||
5. In the ``stable-X`` branch, add, commit, and push changes to ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/archived fragments to the **upstream** repository, NOT to the origin.
|
||||
|
||||
|
||||
Publishing the collection
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
1. In the ``stable-X`` branch, add an annotated tag to the last commit with the collection version ``X.Y.0``. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy <https://galaxy.ansible.com/>`_.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git tag -n # see current tags and their comments
|
||||
git tag -a NEW_VERSION -m "comment here" # the comment can be, for example, "community.foo: 2.1.0"
|
||||
git push upstream NEW_VERSION
|
||||
|
||||
|
||||
2. Wait until the new version is published on the collection's `Ansible Galaxy <https://galaxy.ansible.com/>`_ page. The published version will appear in a list of tarballs available to download.
|
||||
|
||||
3. Add a GitHub release for the new tag. The title should be the version and content, such as - ``See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes``.
|
||||
|
||||
4. Announce the release through the `Bullhorn Newsletter <https://github.com/ansible/community/wiki/News#the-bullhorn>`_.
|
||||
|
||||
5. Announce the release in the pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel <https://docs.ansible.com/ansible/devel/community/communication.html#real-time-chat>`_. Additionally, you can announce it using GitHub's Releases system.
|
||||
|
||||
6. In the ``stable-X`` branch, update the version in ``galaxy.yml`` to the next **expected** version, for example, if you have released ``X.1.0``, the next expected version could be ``X.2.0``. Add, commit and push to the **upstream** repository.
|
||||
|
||||
7. Checkout to the ``main`` branch.
|
||||
|
||||
8. In the ``main`` branch:
|
||||
|
||||
#. If more minor versions are released before the next major version, update the version in ``galaxy.yml`` to ``X.(Y+1).0`` as well. Create a dedicated pull request and merge.
|
||||
|
||||
#. If the next version will be a new major version, create a pull request where you update the version in ``galaxy.yml`` to ``(X+1).0.0``. Note that the sanity tests will most likely fail since there will be deprecations with removal scheduled for ``(X+1).0.0``, which are flagged by the tests.
|
||||
|
||||
For every such deprecation, decide:
|
||||
|
||||
* Whether to remove them now. For example you remove the complete ``modules/plugins`` or you remove redirects.
|
||||
* Whether to add ignore entries to the corresponding ``tests/sanity/ignore-*.txt`` file and create issues, for example for removed features in ``modules/plugins``.
|
||||
|
||||
Once the CI tests pass, merge the pull request. Make sure that this pull request is merged not too much later after the release
|
||||
for ``verison_added`` sanity tests not to expect the wrong version for the new feature pull request.
|
||||
|
||||
.. note::
|
||||
|
||||
It makes sense to already do some removals in the days before the release. These removals must happen in the main branch and must not be backported.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
Releasing when more minor versions are expected
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
1. Checkout the ``X.Y.z`` tag.
|
||||
|
||||
2. Update ``galaxy.yml`` so that the version is ``X.Y.Z``. Add and commit.
|
||||
|
||||
3. Cherry-pick all changes from ``stable-X`` that were added after ``X.Y.z`` and should go into ``X.Y.Z``.
|
||||
|
||||
4. Add a changelog fragment ``changelogs/fragments/X.Y.Z.yml`` with content:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
release_summary: |-
|
||||
Write some text here that should appear as the release summary for this version.
|
||||
The format is reStructuredText but not a list as for regular changelog fragments.
|
||||
This text will be inserted into the changelog.
|
||||
|
||||
Add to git and commit.
|
||||
|
||||
5. Generate the changelogs.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
antsibull-changelog release
|
||||
|
||||
6. Verify that ``CHANGELOG.rst`` looks as expected.
|
||||
|
||||
7. Add and commit changes to ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/archived fragments.
|
||||
|
||||
**Publishing the collection**
|
||||
|
||||
|
||||
1. Add an annotated tag to the last commit with the collection version ``X.Y.Z``. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy <https://galaxy.ansible.com/>`_.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git tag -n # see current tags and their comments
|
||||
git tag -a NEW_VERSION -m "comment here" # the comment can be, for example, "community.foo: 2.1.1"
|
||||
git push upstream NEW_VERSION
|
||||
|
||||
|
||||
2. Wait until the new version is published on the collection's `Ansible Galaxy <https://galaxy.ansible.com/>`_ page. It will appear in a list of tarballs available to download.
|
||||
|
||||
3. Add a GitHub release for the new tag. The title should be the version and content, such as - ``See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes``.
|
||||
|
||||
.. note::
|
||||
|
||||
The data for this release is only contained in a tag, and not in a branch, in particular not in ``stable-X``.
|
||||
This is deliberate, since the next minor release ``X.(Y+1).0`` already contains the changes for ``X.Y.Z`` as well, since these were cherry-picked from ``stable-X``.
|
||||
|
||||
|
||||
4. Announce the release through the `Bullhorn Newsletter <https://github.com/ansible/community/wiki/News#the-bullhorn>`_.
|
||||
|
||||
5. Announce the release in the pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel <https://docs.ansible.com/ansible/devel/community/communication.html#real-time-chat>`.
|
||||
|
||||
|
||||
Releasing when no more minor versions are expected
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
1. In the ``stable-X`` branch, make sure that ``galaxy.yml`` contains the correct version number ``X.Y.Z``. If not, update it!
|
||||
|
||||
2. In the ``stable-X`` branch, add a changelog fragment ``changelogs/fragments/X.Y.Z.yml`` with content:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
release_summary: |-
|
||||
Write some text here that should appear as the release summary for this version.
|
||||
The format is reStructuredText, but not a list as for regular changelog fragments.
|
||||
This text will be inserted into the changelog.
|
||||
|
||||
|
||||
3. Generate the changelogs in the ``stable-X`` branch.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
antsibull-changelog release
|
||||
|
||||
|
||||
4. In the ``stable-X`` branch, verify that ``CHANGELOG.rst`` looks as expected.
|
||||
|
||||
5. In the ``stable-X`` branch, add, commit, and push changes to ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/archived fragments to the **upstream** repository, NOT to the origin.
|
||||
|
||||
**Publishing the collection**
|
||||
|
||||
|
||||
1. In the ``stable-X`` branch, add an annotated tag to the last commit with the collection version ``X.Y.Z``. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy <https://galaxy.ansible.com/>`_.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git tag -n # see current tags and their comments
|
||||
git tag -a NEW_VERSION -m "comment here" # the comment can be, for example, "community.foo: 2.1.1"
|
||||
git push upstream NEW_VERSION
|
||||
|
||||
|
||||
2. Wait until the new version is published on the collection's `Ansible Galaxy <https://galaxy.ansible.com/>`_ page. It will appear in a list of tarballs available to download.
|
||||
|
||||
3. Add a GitHub release for the new tag. Title should be the version and content, such as: ``See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes``.
|
||||
|
||||
4. Announce the release through the `Bullhorn Newsletter <https://github.com/ansible/community/wiki/News#the-bullhorn>`_.
|
||||
|
||||
5. Announce the release in the pinned issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel <https://docs.ansible.com/ansible/devel/community/communication.html#real-time-chat>`_.
|
||||
@ -0,0 +1,115 @@
|
||||
|
||||
.. _collection_release_without_branches:
|
||||
|
||||
Releasing collections without release branches
|
||||
===============================================
|
||||
|
||||
Since no release branches are used, this section does not distinguish between releasing a major, minor, or patch version.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
||||
Release planning and announcement
|
||||
----------------------------------
|
||||
|
||||
#. Examine the collection to determine if there are merged changes to release.
|
||||
|
||||
#. According to the changes made, choose an appropriate release version number. Keep in mind that the collections must follow the `semantic versioning <https://semver.org/>`_ rules. See :ref:`collection_versioning_and_deprecation` for details.
|
||||
|
||||
#. Announce your intention to release the collection in a corresponding pinned release issue or community pinboard of the collection and in the ``community`` :ref:`Matrix/IRC channel <communication_irc>`.
|
||||
|
||||
Creating the release branch
|
||||
----------------------------
|
||||
|
||||
1. Ensure you are in a default branch in your local fork. We use ``main`` in the following examples.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
git status
|
||||
git checkout main # if needed
|
||||
|
||||
|
||||
2. Update your local fork:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
git pull --rebase upstream main
|
||||
|
||||
|
||||
3. Checkout a new release branch from the default branch:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
git checkout -b release_branch
|
||||
|
||||
4. Ensure the ``galaxy.yml`` contains the correct release version number.
|
||||
|
||||
|
||||
Generating the changelog
|
||||
-------------------------
|
||||
|
||||
1. Add a changelog fragment ``changelogs/fragments/X.Y.Z.yml`` with content:
|
||||
|
||||
.. code:: yaml
|
||||
|
||||
release_summary: |-
|
||||
Write some text here that should appear as the release summary for this version.
|
||||
The format is reStructuredText, but not a list as for regular changelog fragments.
|
||||
This text will be inserted into the changelog.
|
||||
|
||||
For example:
|
||||
|
||||
.. code:: yaml
|
||||
|
||||
release_summary: |-
|
||||
This is the minor release of the ``community.mysql`` collection.
|
||||
This changelog contains all changes to the modules and plugins in this collection
|
||||
that have been made after the previous release.
|
||||
|
||||
|
||||
2. If the content was recently moved from another collection (for example, migrating a module from one collection to another), ensure you have all related changelog fragments in the ``changelogs/fragments`` directory. If not, copy them previously.
|
||||
|
||||
3. Run ``antsibull-changelog release --reload-plugins`` . This package should previously be installed with ``pip install antsibull-changelog``.
|
||||
|
||||
4. Verify that the ``CHANGELOG.rst`` looks as expected.
|
||||
|
||||
5. Commit and push changes to the ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/archived fragments to the ``origin`` repository's ``release_branch``.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
git commit -a -m "Release VERSION commit"
|
||||
git push origin release_branch
|
||||
|
||||
|
||||
6. Create a pull request in the collection repository. If CI tests pass, merge it.
|
||||
|
||||
7. Checkout the default branch and pull the changes:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
git checkout main
|
||||
git pull --rebase upstream main
|
||||
|
||||
|
||||
Publish the collection
|
||||
-----------------------------------
|
||||
|
||||
1. Add an annotated tag to the release commit with the collection version. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy <https://galaxy.ansible.com/>`_.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
git tag -n # see current tags and their comments
|
||||
git tag -a NEW_VERSION -m "comment here" # the comment can be, for example, "community.postgresql: 1.2.0"
|
||||
git push upstream NEW_VERSION
|
||||
|
||||
|
||||
|
||||
2. Wait until the new version is published on the collection's `Ansible Galaxy <https://galaxy.ansible.com/>`_ page. It will appear in a list of tarballs available to download.
|
||||
|
||||
3. Update the version in the ``galaxy.yml`` file to the next **expected** version. Add, commit, and push to the ``upstream``'s default branch.
|
||||
|
||||
4. Add a GitHub release for the new tag. Title should be the version and content ``See https://github.com/ansible-collections/community.xxx/blob/main/CHANGELOG.rst for all changes``.
|
||||
|
||||
5. Announce the release through the `Bullhorn Newsletter issue <https://github.com/ansible/community/wiki/News#the-bullhorn>`_.
|
||||
|
||||
6. Announce the release in the pinned release issue/community pinboard of the collection mentioned in step 3 and in the ``community`` :ref:`Matrix/IRC channel <communication_irc>`.
|
||||
@ -0,0 +1,106 @@
|
||||
|
||||
.. _releasing_collections:
|
||||
.. _Releasing:
|
||||
|
||||
Releasing collections
|
||||
======================
|
||||
|
||||
Collection maintainers release all supported stable versions of the collections regularly,
|
||||
provided that there have been enough changes merged to release.
|
||||
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
||||
Preparing to release a collection
|
||||
--------------------------------------------
|
||||
|
||||
|
||||
The collections under the `ansible-collections organization <https://github.com/ansible-collections>`_ follow `semantic versioning <https://semver.org/>`_ when releasing. See :ref:`collection_versioning_and_deprecation` for details.
|
||||
|
||||
To prepare for a release, a collection must have:
|
||||
|
||||
* A publicly available policy of releasing, versioning, and deprecation. This can be, for example, written in its README or in a dedicated pinned issue.
|
||||
* A pinned issue when its release managers inform the community about planned or completed releases. This can be combined with the release policy issue mentioned above.
|
||||
* A :ref:`changelog <collection_changelogs>`.
|
||||
* Releases of the collection tagged in the collection's repository.
|
||||
* CI pipelines up and running. This can be implemented by using GitHub Actions, Azure Pipelines, Zuul.
|
||||
* All CI tests running against a commit that releases the collection. If they do not pass, the collection MUST NOT be released.
|
||||
|
||||
See :ref:`including_collection_ansible` if you plan on adding a new collection to the Ansible package.
|
||||
|
||||
.. note::
|
||||
|
||||
Your collection must pass ``ansible-test sanity`` tests. See :ref:`testing_collections` for details.
|
||||
|
||||
|
||||
.. _collection_versioning_and_deprecation:
|
||||
|
||||
Collection versioning and deprecation
|
||||
--------------------------------------
|
||||
|
||||
.. note::
|
||||
|
||||
Collections MUST adhere to `semantic versioning <https://semver.org/>`_.
|
||||
|
||||
To preserve backward compatibility for users, every Ansible minor version series (5.1.x, 5.2.x, and so on) will keep the major version of a collection constant. For example, if Ansible 5.0.0 includes ``community.general`` 4.0.2, then each Ansible 5.X.x release will include the latest ``community.general`` 4.y.z release available at build time. Ansible 5.x.x will **never** include a ``community.general`` 5.y.x release, even if it is available. Major collection version changes will be included in the next Ansible major release (6.0.0 in this case).
|
||||
Ensure that the current major release of your collection included in 6.0.0 receives at least bugfixes as long as new Ansible 6.X.X releases are produced.
|
||||
|
||||
Since new minor releases are included, you can include new features, modules and plugins. You must make sure that you do not break backwards compatibility. See `semantic versioning <https://semver.org/>`_. for more details. This means in particular:
|
||||
|
||||
* You can fix bugs in **patch** releases but not add new features or deprecate things.
|
||||
* You can add new features and deprecate things in **minor** releases, but not remove things or change behavior of existing features.
|
||||
* You can only remove things or make breaking changes in **major** releases.
|
||||
|
||||
Ensure that if a deprecation is added in a collection version that is included in 5.x.y, the removal itself will only happen in a collection version included in 7.0.0 or later.
|
||||
Ensure that the policy of releasing, versioning, and deprecation is announced to contributors and users in some way. For an example of how to do this, see `the announcement in community.general <https://github.com/ansible-collections/community.general/issues/582>`_. You could also do this in the collection README file.
|
||||
|
||||
.. _collection_changelog:
|
||||
|
||||
Collection changelogs
|
||||
----------------------
|
||||
|
||||
Collections MUST include a changelog. To give a consistent feel for changelogs across collections and ensure changelogs exist for collections included in the ``ansible`` package, we suggest you use `antsibull-changelog <https://github.com/ansible-community/antsibull-changelog>`_ to maintain and generate this.
|
||||
|
||||
Before releasing, verify the following for your changelogs:
|
||||
|
||||
* All merged pull requests since the last release, except ones related to documentation and new modules/plugins, have :ref:`changelog fragments <collection_changelog_fragments>`.
|
||||
* New module and plugin pull requests, except jinja2 test and filter plugins, do **not** need a changelog fragment, they are auto-detected by the changelog generator by their ``version_added`` value.
|
||||
* All the fragments follow the :ref:`changelog entry format <collection_changelogs_how_to_format>`.
|
||||
|
||||
Options for releasing a collection
|
||||
-----------------------------------
|
||||
|
||||
There are several approaches on how to release a collection. If you are not aware of which approach to use, ask in the ``#ansible-community`` IRC channel or the ``community`` Matrix channel.
|
||||
|
||||
This section assumes that publishing the collection is done with `Zuul <https://github.com/ansible/project-config>`_ and that `antsibull-changelog <https://github.com/ansible-community/antsibull-changelog>`_ is used for the changelog.
|
||||
|
||||
Releasing without release branches
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Use releasing without release branches when:
|
||||
|
||||
* There are no prior major releases of the collection.
|
||||
* There are no breaking changes introduced since the ``1.0.0`` release of the collection.
|
||||
|
||||
See :ref:`collection_release_without_branches` for details.
|
||||
|
||||
When there is a need to introduce breaking changes, you can switch to the next approach.
|
||||
|
||||
Hybrid approach
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
In this approach, releases for the current major version are made from the ``main`` branch, while new releases for older major versions are made from release branches for these versions.
|
||||
|
||||
Releasing with release branches
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Use releasing with release branches when breaking changes have been introduced. This approach is usually only used by the large community collections, ``community.general`` and ``community.network``.
|
||||
|
||||
See :ref:`collection_release_with_branches` for details.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
collection_release_without_branches
|
||||
collection_release_with_branches
|
||||
@ -66,6 +66,8 @@ More precisely:
|
||||
|
||||
We build short summary changelogs for minor releases as well as for major releases. If you backport a bugfix, include a changelog fragment with the backport PR.
|
||||
|
||||
.. _collection_changelogs_how_to_format:
|
||||
|
||||
Creating a changelog fragment
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
@ -151,7 +153,8 @@ A single changelog fragment may contain multiple sections but most will only con
|
||||
|
||||
Each changelog entry must contain a link to its issue between parentheses at the end. If there is no corresponding issue, the entry must contain a link to the PR itself.
|
||||
|
||||
Most changelog entries are ``bugfixes`` or ``minor_changes``.
|
||||
Most changelog entries are ``bugfixes`` or ``minor_changes``. You can also use ``trivial`` for any collection that requires a changelog fragment for each pull request. ``trivial`` changelog fragments are excluded from the changelog output.
|
||||
|
||||
|
||||
Changelog fragment entry format
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
@ -86,10 +86,10 @@ General channels
|
||||
|
||||
The clickable links will take you directly to the relevant Matrix room in your browser; room/channel information is also given for use in other clients:
|
||||
|
||||
- `Community social room and posting news for the Bullhorn newsletter <https://matrix.to:/#/#social:ansible.im>`_ - ``Matrix: #social:ansible.im | IRC: #ansible-social``
|
||||
- `General usage and support questions <https://matrix.to:/#/#users:ansible.im>`_ - ``Matrix: #users:ansible.im | IRC: #ansible``
|
||||
- `Discussions on developer topics and code related to features or bugs <https://matrix.to/#/#devel:ansible.im>`_ - ``Matrix: #devel:ansible.im | IRC: #ansible-devel``
|
||||
- `Discussions on community and collections related topics <https://matrix.to:/#/#community:ansible.im>`_ - ``Matrix: #community:ansible.im | IRC: #ansible-community``
|
||||
- `Community social room and posting news for the Bullhorn newsletter <https://matrix.to:/#/#social:ansible.com>`_ - ``Matrix: #social:ansible.com | IRC: #ansible-social``
|
||||
- `General usage and support questions <https://matrix.to:/#/#users:ansible.com>`_ - ``Matrix: #users:ansible.com | IRC: #ansible``
|
||||
- `Discussions on developer topics and code related to features or bugs <https://matrix.to/#/#devel:ansible.com>`_ - ``Matrix: #devel:ansible.com | IRC: #ansible-devel``
|
||||
- `Discussions on community and collections related topics <https://matrix.to:/#/#community:ansible.com>`_ - ``Matrix: #community:ansible.com | IRC: #ansible-community``
|
||||
- `For public community meetings <https://matrix.to/#/#meeting:ansible.im>`_ - ``Matrix: #meeting:ansible.im | IRC: #ansible-meeting``
|
||||
- We will generally announce these on one or more of the above mailing lists. See the `meeting schedule and agenda page <https://github.com/ansible/community/blob/master/meetings/README.md>`_
|
||||
|
||||
@ -100,28 +100,28 @@ Working groups
|
||||
|
||||
Many of our community `Working Groups <https://github.com/ansible/community/wiki#working-groups>`_ meet in chat. If you want to get involved in a working group, join the Matrix room or IRC channel where it meets or comment on the agenda.
|
||||
|
||||
- `Amazon (AWS) Working Group <https://github.com/ansible/community/wiki/AWS>`_ - Matrix: `#aws:ansible.im <https://matrix.to:/#/#aws:ansible.im>`_ | IRC: ``#ansible-aws``
|
||||
- `Ansible Lockdown Working Group <https://github.com/ansible/community/wiki/Lockdown>`_ (`Security playbooks/roles <https://github.com/ansible/ansible-lockdown>`_) - Matrix: `#lockdown:ansible.im <https://matrix.to:/#/#lockdown:ansible.im>`_ | IRC: ``#ansible-lockdown``
|
||||
- `AWX Working Group <https://github.com/ansible/awx>`_ - Matrix: `#awx:ansible.im <https://matrix.to:/#/#awx:ansible.im>`_ | IRC: ``#ansible-awx``
|
||||
- `Azure Working Group <https://github.com/ansible/community/wiki/Azure>`_ - Matrix: `#azure:ansible.im <https://matrix.to:/#/#azure:ansible.im>`_ | IRC: ``#ansible-azure``
|
||||
- `Community Working Group <https://github.com/ansible/community/wiki/Community>`_ (including Meetups) - Matrix: `#community:ansible.im <https://matrix.to:/#/#community:ansible.im>`_ | IRC: ``#ansible-community``
|
||||
- `Container Working Group <https://github.com/ansible/community/wiki/Container>`_ - Matrix: `#container:ansible.im <https://matrix.to:/#/#container:ansible.im>`_ | IRC: ``#ansible-container``
|
||||
- `Contributor Experience Working Group <https://github.com/ansible/community/wiki/Contributor-Experience>`_ - Matrix: `#community:ansible.im <https://matrix.to:/#/#community:ansible.im>`_ | IRC: ``#ansible-community``
|
||||
- `Amazon (AWS) Working Group <https://github.com/ansible/community/wiki/AWS>`_ - Matrix: `#aws:ansible.com <https://matrix.to:/#/#aws:ansible.com>`_ | IRC: ``#ansible-aws``
|
||||
- `Ansible Lockdown Working Group <https://github.com/ansible/community/wiki/Lockdown>`_ (`Security playbooks/roles <https://github.com/ansible/ansible-lockdown>`_) - Matrix: `#lockdown:ansible.com <https://matrix.to:/#/#lockdown:ansible.com>`_ | IRC: ``#ansible-lockdown``
|
||||
- `AWX Working Group <https://github.com/ansible/awx>`_ - Matrix: `#awx:ansible.com <https://matrix.to:/#/#awx:ansible.com>`_ | IRC: ``#ansible-awx``
|
||||
- `Azure Working Group <https://github.com/ansible/community/wiki/Azure>`_ - Matrix: `#azure:ansible.com <https://matrix.to:/#/#azure:ansible.com>`_ | IRC: ``#ansible-azure``
|
||||
- `Community Working Group <https://github.com/ansible/community/wiki/Community>`_ (including Meetups) - Matrix: `#community:ansible.com <https://matrix.to:/#/#community:ansible.com>`_ | IRC: ``#ansible-community``
|
||||
- `Container Working Group <https://github.com/ansible/community/wiki/Container>`_ - Matrix: `#container:ansible.com <https://matrix.to:/#/#container:ansible.com>`_ | IRC: ``#ansible-container``
|
||||
- `Contributor Experience Working Group <https://github.com/ansible/community/wiki/Contributor-Experience>`_ - Matrix: `#community:ansible.com <https://matrix.to:/#/#community:ansible.com>`_ | IRC: ``#ansible-community``
|
||||
- `DigitalOcean Working Group <https://github.com/ansible/community/wiki/Digital-Ocean>`_ - Matrix: `#digitalocean:ansible.im <https://matrix.to:/#/#digitalocean:ansible.im>`_ | IRC: ``#ansible-digitalocean``
|
||||
- `Diversity Working Group <https://github.com/ansible/community/wiki/Diversity>`_ - Matrix: `#diversity:ansible.im <https://matrix.to:/#/#diversity:ansible.im>`_ | IRC: ``#ansible-diversity``
|
||||
- `Docker Working Group <https://github.com/ansible/community/wiki/Docker>`_ - Matrix: `#devel:ansible.im <https://matrix.to:/#/#devel:ansible.im>`_ | IRC: ``#ansible-devel``
|
||||
- `Documentation Working Group <https://github.com/ansible/community/wiki/Docs>`_ - Matrix: `#docs:ansible.im <https://matrix.to:/#/#docs:ansible.im>`_ | IRC: ``#ansible-docs``
|
||||
- `Galaxy Working Group <https://github.com/ansible/community/wiki/Galaxy>`_ - Matrix: `#galaxy:ansible.im <https://matrix.to:/#/#galaxy:ansible.im>`_ | IRC: ``#ansible-galaxy``
|
||||
- `JBoss Working Group <https://github.com/ansible/community/wiki/JBoss>`_ - Matrix: `#jboss:ansible.im <https://matrix.to:/#/#jboss:ansible.im>`_ | IRC: ``#ansible-jboss``
|
||||
- `Kubernetes Working Group <https://github.com/ansible/community/wiki/Kubernetes>`_ - Matrix: `#kubernetes:ansible.im <https://matrix.to:/#/#kubernetes:ansible.im>`_ | IRC: ``#ansible-kubernetes``
|
||||
- `Linode Working Group <https://github.com/ansible/community/wiki/Linode>`_ - Matrix: `#linode:ansible.im <https://matrix.to:/#/#linode:ansible.im>`_ | IRC: ``#ansible-linode``
|
||||
- `Diversity Working Group <https://github.com/ansible/community/wiki/Diversity>`_ - Matrix: `#diversity:ansible.com <https://matrix.to:/#/#diversity:ansible.com>`_ | IRC: ``#ansible-diversity``
|
||||
- `Docker Working Group <https://github.com/ansible/community/wiki/Docker>`_ - Matrix: `#devel:ansible.com <https://matrix.to:/#/#devel:ansible.com>`_ | IRC: ``#ansible-devel``
|
||||
- `Documentation Working Group <https://github.com/ansible/community/wiki/Docs>`_ - Matrix: `#docs:ansible.com <https://matrix.to:/#/#docs:ansible.com>`_ | IRC: ``#ansible-docs``
|
||||
- `Galaxy Working Group <https://github.com/ansible/community/wiki/Galaxy>`_ - Matrix: `#galaxy:ansible.com <https://matrix.to:/#/#galaxy:ansible.com>`_ | IRC: ``#ansible-galaxy``
|
||||
- `JBoss Working Group <https://github.com/ansible/community/wiki/JBoss>`_ - Matrix: `#jboss:ansible.com <https://matrix.to:/#/#jboss:ansible.com>`_ | IRC: ``#ansible-jboss``
|
||||
- `Kubernetes Working Group <https://github.com/ansible/community/wiki/Kubernetes>`_ - Matrix: `#kubernetes:ansible.com <https://matrix.to:/#/#kubernetes:ansible.com>`_ | IRC: ``#ansible-kubernetes``
|
||||
- `Linode Working Group <https://github.com/ansible/community/wiki/Linode>`_ - Matrix: `#linode:ansible.com <https://matrix.to:/#/#linode:ansible.com>`_ | IRC: ``#ansible-linode``
|
||||
- `Molecule Working Group <https://github.com/ansible/community/wiki/Molecule>`_ (`testing platform for Ansible playbooks and roles <https://molecule.readthedocs.io>`_) - Matrix: `#molecule:ansible.im <https://matrix.to:/#/#molecule:ansible.im>`_ | IRC: ``#ansible-molecule``
|
||||
- `Network Working Group <https://github.com/ansible/community/wiki/Network>`_ - Matrix: `#network:ansible.im <https://matrix.to:/#/#network:ansible.im>`_ | IRC: ``#ansible-network``
|
||||
- `Remote Management Working Group <https://github.com/ansible/community/issues/409>`_ - Matrix: `#devel:ansible.im <https://matrix.to:/#/#devel:ansible.im>`_ | IRC: ``#ansible-devel``
|
||||
- `Testing Working Group <https://github.com/ansible/community/wiki/Testing>`_ - Matrix: `#devel:ansible.im <https://matrix.to:/#/#devel:ansible.im>`_ | IRC: ``#ansible-devel``
|
||||
- `VMware Working Group <https://github.com/ansible/community/wiki/VMware>`_ - Matrix: `#vmware:ansible.im <https://matrix.to:/#/#vmware:ansible.im>`_ | IRC: ``#ansible-vmware``
|
||||
- `Windows Working Group <https://github.com/ansible/community/wiki/Windows>`_ - Matrix: `#windows:ansible.im <https://matrix.to:/#/#windows:ansible.im>`_ | IRC: ``#ansible-windows``
|
||||
- `Ansible developer tools Group <https://github.com/ansible/community/wiki/Ansible-developer-tools>`_ - Matrix: `devtools:ansible.im <https://matrix.to/#/#devtools:ansible.im>`_ | IRC: ``#ansible-devtools``
|
||||
- `Network Working Group <https://github.com/ansible/community/wiki/Network>`_ - Matrix: `#network:ansible.com <https://matrix.to:/#/#network:ansible.com>`_ | IRC: ``#ansible-network``
|
||||
- `Remote Management Working Group <https://github.com/ansible/community/issues/409>`_ - Matrix: `#devel:ansible.com <https://matrix.to:/#/#devel:ansible.com>`_ | IRC: ``#ansible-devel``
|
||||
- `Testing Working Group <https://github.com/ansible/community/wiki/Testing>`_ - Matrix: `#devel:ansible.com <https://matrix.to:/#/#devel:ansible.com>`_ | IRC: ``#ansible-devel``
|
||||
- `VMware Working Group <https://github.com/ansible/community/wiki/VMware>`_ - Matrix: `#vmware:ansible.com <https://matrix.to:/#/#vmware:ansible.com>`_ | IRC: ``#ansible-vmware``
|
||||
- `Windows Working Group <https://github.com/ansible/community/wiki/Windows>`_ - Matrix: `#windows:ansible.com <https://matrix.to:/#/#windows:ansible.com>`_ | IRC: ``#ansible-windows``
|
||||
- `Ansible developer tools Group <https://github.com/ansible/community/wiki/Ansible-developer-tools>`_ - Matrix: `#devtools:ansible.com <https://matrix.to/#/#devtools:ansible.com>`_ | IRC: ``#ansible-devtools``
|
||||
|
||||
Want to `form a new Working Group <https://github.com/ansible/community/blob/master/WORKING-GROUPS.md>`_?
|
||||
|
||||
|
||||
@ -11,10 +11,10 @@ Ansible Collections Contributor Guide
|
||||
reporting_collections
|
||||
create_pr_quick_start
|
||||
collection_contributors/test_index
|
||||
documentation_contributions
|
||||
maintainers
|
||||
contributing_maintained_collections
|
||||
steering/steering_index
|
||||
documentation_contributions
|
||||
other_tools_and_programs
|
||||
|
||||
|
||||
|
||||
104
docs/docsite/rst/community/contributor_path.rst
Normal file
104
docs/docsite/rst/community/contributor_path.rst
Normal file
@ -0,0 +1,104 @@
|
||||
****************
|
||||
Contributor path
|
||||
****************
|
||||
|
||||
This section describes the contributor journey from the beginning to becoming a leader who helps shape the future of Ansible. You can use this path as a roadmap for your long-term participation.
|
||||
|
||||
Any contribution to the project, even a small one, is very welcome and valuable. Any contribution counts, whether it's feedback on an issue, a pull request, a topic or documentation change, or a coding contribution. When you contribute regularly, your proficiency and judgment in the related area increase and, along with this, the importance of your presence in the project.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
||||
|
||||
|
||||
Determine your area of interest
|
||||
=================================
|
||||
|
||||
First, determine areas that are interesting to you. Consider your current experience and what you'd like to gain. For example, if you use a specific collection, have a look there. See :ref:`how_can_i_help` for more ideas on how to help.
|
||||
|
||||
Find the corresponding project
|
||||
====================================
|
||||
|
||||
These are multiple community projects in the Ansible ecosystem you could contribute to:
|
||||
|
||||
- `Ansible Core <https://docs.ansible.com/ansible-core/devel/index.html>`_
|
||||
- `Collections <https://docs.ansible.com/ansible/latest/user_guide/collections_using.html>`_
|
||||
- `AWX <https://github.com/ansible/awx>`_
|
||||
- `Galaxy <https://galaxy.ansible.com/>`_
|
||||
- `ansible-lint <https://ansible-lint.readthedocs.io/en/latest/>`_
|
||||
- `Molecule <https://molecule.readthedocs.io/en/latest/>`_
|
||||
|
||||
Learn
|
||||
=====
|
||||
|
||||
The required skillset depends on the area of interest and the project you'll be working on. Remember that the best way to learn is by doing.
|
||||
|
||||
Specific knowledge for code developers
|
||||
----------------------------------------
|
||||
|
||||
Code development requires the most technical knowledge. Let's sort out what an Ansible developer should learn.
|
||||
|
||||
|
||||
You should understand at least *basics* of the following tools:
|
||||
|
||||
- `Python programming language <https://docs.python.org/3/tutorial/>`_
|
||||
- `Git <https://git-scm.com/docs/gittutorial>`_
|
||||
- `GitHub collaborative development model through forks and pull requests <https://docs.github.com/en/github/collaborating-with-pull-requests/getting-started/about-collaborative-development-models>`_
|
||||
|
||||
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.
|
||||
|
||||
* :ref:`Ansible Core development <developer_guide>`.
|
||||
* :ref:`Ansible collectoin development <developing_collections>` and the collection-level contributor guidelines in the collection repository.
|
||||
|
||||
|
||||
Making your first contribution
|
||||
==============================
|
||||
|
||||
You can find some ideas on how you can contribute in :ref:`how_can_i_help` and the `collection repository <https://github.com/ansible-collections/>`_ ``README`` and ``CONTRIBUTING`` files. To make your first experience as smooth as possible, read the repository documentation carefully, then ask the repository maintainers for guidance if you have any questions.
|
||||
|
||||
You can also look for GitHub issues labeled with the ``easyfix``, ``good_first_issue``, and ``docs`` labels. Add a comment on the GitHub issue to say you are looking at it and to ask for help if you need it.
|
||||
|
||||
Continue to contribute
|
||||
======================
|
||||
|
||||
We don't expect everybody to know everything. Start small, think big. When you contribute regularly, your proficiency and judgment in the related area will improve quickly and, along with this, the importance of your presence in the project.
|
||||
|
||||
See :ref:`communication` for ways to communicate and engage with the Ansible community, including working group meetings, accessing the Bullhorn news bulletin, and upcoming contributor summits.
|
||||
|
||||
|
||||
Teach others
|
||||
============
|
||||
|
||||
Share your experience with other contributors through `improving documentation <ommunity_documentation_contributions>`, answering question from other contributors and users on `Matrix/Libera.Chat IRC <communicate>`, giving advice in issues and pull requests, and discussing the `Community Topics <https://github.com/ansible-community/community-topics/issues>`_.
|
||||
|
||||
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 <https://github.com/ansible-community/collection_bot>`_ , such as `community.general <https://github.com/ansible-collections/community.general>`_ and `community.network <https://github.com/ansible-collections/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.
|
||||
* ``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 <https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization>`_.
|
||||
|
||||
Become a steering committee member
|
||||
==================================
|
||||
|
||||
.. note::
|
||||
|
||||
You do NOT have to be a programmer to become a steering committee member.
|
||||
|
||||
The `Steering Committee <community_steering_committee>` member status reflects the highest level of trust which allows contributors to lead the project through making very important `decisions <https://github.com/ansible-community/community-topics/issues>`_ 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:
|
||||
|
||||
* Subscribe to, comment on, and vote on the `Community Topics <https://github.com/ansible-community/community-topics/issues>`_.
|
||||
* Propose your topics.
|
||||
* If time permits, join the `Community meetings <https://github.com/ansible/community/blob/main/meetings/README.md#schedule>`_ Note this is **NOT** a requirement.
|
||||
@ -249,7 +249,9 @@ A single changelog fragment may contain multiple sections but most will only con
|
||||
|
||||
Each changelog entry must contain a link to its issue between parentheses at the end. If there is no corresponding issue, the entry must contain a link to the PR itself.
|
||||
|
||||
Most changelog entries are ``bugfixes`` or ``minor_changes``.
|
||||
Most changelog entries are ``bugfixes`` or ``minor_changes``. The changelog tool also supports ``trivial``, which are not listed in the actual changelog output but are used by collections repositories that require a changelog fragment for each PR.
|
||||
|
||||
|
||||
|
||||
.. _changelogs_how_to_format:
|
||||
|
||||
|
||||
@ -48,7 +48,10 @@ If there is no meetup near you, we are happy to help you `start one <https://www
|
||||
File and verify issues
|
||||
======================
|
||||
|
||||
All software has bugs, and Ansible is no exception. When you find a bug, you can help tremendously by :ref:`telling us about it <reporting_bugs_and_features>`.
|
||||
All software has bugs, and Ansible is no exception. When you find a bug, you can help tremendously by telling us about it:
|
||||
|
||||
* Filing :ref:`issues for ansible-core <reporting_bugs_and_features>`.
|
||||
* Filing :ref:`issues for collections <reporting_bugs_in_collections>`.
|
||||
|
||||
|
||||
If the bug you found already exists in an issue, you can help by verifying the behavior of the reported bug with a comment in that issue, or by reporting any additional information.
|
||||
@ -56,16 +59,16 @@ If the bug you found already exists in an issue, you can help by verifying the b
|
||||
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:`Ansible development process <community_development_process>` and and :ref:`how to contribute to collections <contributing_maintained_collections>` to learn how to get your code accepted into Ansible.
|
||||
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 <community_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. The Ansible community keeps a full list of `open pull requests by file <https://ansible.sivel.net/pr/byfile.html>`_, 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.
|
||||
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 <https://ansible.sivel.net/pr/byfile.html>`_, 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.
|
||||
|
||||
Become a collection maintainer
|
||||
==============================
|
||||
|
||||
Once you have learned about the development process and have contributed code to a collection, we encourage you to become a maintainer of that collection. There are hundreds of modules in dozens of Ansible collections, and the vast majority of them are written and maintained entirely by members of the Ansible community.
|
||||
|
||||
To learn more about the responsibilities of being an Ansible module maintainer, please read our :ref:`collection maintainer guidelines <maintainers>`.
|
||||
See :ref:`collection maintainer guidelines <maintainers>` to learn more about the responsibilities of being an Ansible collection maintainer.
|
||||
|
||||
.. _community_working_groups:
|
||||
|
||||
|
||||
@ -21,3 +21,4 @@ The purpose of this guide is to teach you everything you need to know about bein
|
||||
:maxdepth: 2
|
||||
|
||||
getting_started
|
||||
contributor_path
|
||||
|
||||
@ -11,6 +11,7 @@ Thank you for being a community collection maintainer. This guide offers an over
|
||||
|
||||
maintainers_guidelines
|
||||
maintainers_workflow
|
||||
collection_contributors/collection_releasing
|
||||
|
||||
In addition to the information here, module maintainers should be familiar with:
|
||||
|
||||
|
||||
@ -66,7 +66,7 @@ The quarterly Ansible Contributor Summit is a global event that provides our con
|
||||
Weekly community Matrix/IRC meetings
|
||||
------------------------------------
|
||||
|
||||
The Community and the Steering Committee come together at weekly meetings in the ``#ansible-community`` :ref:`Matrix/Libera.Chat <https://docs.ansible.com/ansible/devel/community/communication.html#real-time-chat>` channel to discuss important project-scale questions. See the `schedule <https://github.com/ansible/community/blob/main/meetings/README.md#schedule>`_ and join.
|
||||
The Community and the Steering Committee come together at weekly meetings in the ``#ansible-community`` :ref:`Matrix/Libera.Chat <communication_irc>` channel to discuss important project-scale questions. See the `schedule <https://github.com/ansible/community/blob/main/meetings/README.md#schedule>`_ and join.
|
||||
|
||||
Expanding the collection community
|
||||
===================================
|
||||
@ -108,7 +108,16 @@ Promote active contributors satisfying :ref:`requirements<maintainer_requirement
|
||||
|
||||
If your collection found new maintainers, announce that fact in the `Bullhorn newsletter <https://github.com/ansible/community/wiki/News#the-bullhorn>`_ and during the next Contributor Summit congratulating and thanking them for the work done. You can mention all the people promoted since the previous summit. Remember to invite the other maintainers to the Summit in advance.
|
||||
|
||||
Some other general guidelines to encourage contributors:
|
||||
|
||||
* Welcome the author and thank them for the issue or pull request.
|
||||
* If there is a non-crucial easy-fix bug reported, politely ask the author to fix it themselves providing a link to :ref:`collection_quickstart`.
|
||||
* When suggesting changes, try to use questions, not statements.
|
||||
* When suggesting mandatory changes, do it as politely as possible providing documentation references.
|
||||
* If your suggestion is optional or a matter of personal preferences, please say it explicitly.
|
||||
* When asking for adding tests or for complex code refactoring, say that the author is welcome to ask for clarifications and help if they need.
|
||||
* If somebody suggests a good idea, mention it or put a thumbs up.
|
||||
* After merging, thank the author and reviewers for their time and effort.
|
||||
|
||||
.. _maintainer_documentation:
|
||||
|
||||
|
||||
@ -1,20 +1,5 @@
|
||||
.. _maintainers_workflow:
|
||||
|
||||
.. _Releasing:
|
||||
|
||||
Releasing collections
|
||||
======================
|
||||
|
||||
Collection maintainers release all supported stable versions of the collections regularly,
|
||||
provided that there have been enough changes merged to release.
|
||||
|
||||
Generally, releasing in the collections consists of:
|
||||
|
||||
1. Planning and announcement.
|
||||
2. Generating a changelog.
|
||||
3. Creating a release git tag and pushing it.
|
||||
4. Automatic publishing the release tarball on `Ansible Galaxy <https://galaxy.ansible.com/>`_ by `Zuul <https://dashboard.zuul.ansible.com/t/ansible/builds?pipeline=release>`_.
|
||||
5. Final announcement.
|
||||
|
||||
Backporting and Ansible inclusion
|
||||
==================================
|
||||
@ -59,6 +44,20 @@ For more information about the collection bot and its interface,
|
||||
see to the `Collection bot overview <https://github.com/ansible-community/collection_bot/blob/main/ISSUE_HELP.md>`_.
|
||||
|
||||
|
||||
Releasing a collection
|
||||
----------------------
|
||||
|
||||
Collection maintainers are responsible for releasing new versions of a collection. Generally, releasing in the collections consists of:
|
||||
|
||||
#. Planning and announcement.
|
||||
#. Generating a changelog.
|
||||
#. Creating a release git tag and pushing it.
|
||||
#. Automaticly publishing the release tarball on `Ansible Galaxy <https://galaxy.ansible.com/>`_ through the `Zuul dashboard <https://dashboard.zuul.ansible.com/t/ansible/builds?pipeline=release>`_.
|
||||
#. Final announcement.
|
||||
#. Optionally, `file a request to include a new collection into the Ansible package <https://github.com/ansible-collections/ansible-inclusion>`_.
|
||||
|
||||
See :ref:`releasing_collections` for details.
|
||||
|
||||
.. _Backporting:
|
||||
|
||||
Backporting
|
||||
@ -72,10 +71,12 @@ The manual backport process is similar to the :ref:`ansible-core backporting gui
|
||||
For convenience, backporting can be implemented automatically using GitHub bots (for example, with the `Patchback app <https://github.com/apps/patchback>`_) and labeling as it is done in `community.general <https://github.com/ansible-collections/community.general>`_ and `community.network <https://github.com/ansible-collections/community.network>`_.
|
||||
|
||||
|
||||
Inclusion in Ansible
|
||||
----------------------
|
||||
.. _including_collection_ansible:
|
||||
|
||||
If a collection is not included in Ansible (not shipped with Ansible package), maintainers can submit the collection for inclusion by creating a discussion under `ansible-collections/ansible-inclusion repository <https://github.com/ansible-collections/ansible-inclusion>`_. For more information, see the `repository's README <https://github.com/ansible-collections/ansible-inclusion/blob/main/README.md>`_.
|
||||
Including a collection in Ansible
|
||||
-----------------------------------
|
||||
|
||||
If a collection is not included in Ansible (not shipped with Ansible package), maintainers can submit the collection for inclusion by creating a discussion under `ansible-collections/ansible-inclusion repository <https://github.com/ansible-collections/ansible-inclusion>`_. For more information, see the `repository's README <https://github.com/ansible-collections/ansible-inclusion/blob/main/README.md>`_, and the `Ansible community package collections requirements <https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst>`.
|
||||
|
||||
Stepping down as a collection maintainer
|
||||
===========================================
|
||||
|
||||
@ -16,7 +16,7 @@ Reporting a bug
|
||||
Security bugs
|
||||
-------------
|
||||
|
||||
Ansible practices responsible disclosure - for security-related bugs, email `security@ansible.com <mailto:security@ansible.com>`_ to receive a prompt response. Do not submit a ticket or post to any public groups.
|
||||
Ansible practices responsible disclosure. To report security-related bugs, send an email to `security@ansible.com <mailto:security@ansible.com>`_ for an immediate response. Do not submit a ticket or post to any public groups.
|
||||
|
||||
Bugs in ansible-core
|
||||
--------------------
|
||||
@ -38,17 +38,16 @@ If you find a bug, open an issue using the `issue template <https://github.com/a
|
||||
|
||||
Fill out the issue template as completely and as accurately as possible. Include:
|
||||
|
||||
* your Ansible version
|
||||
* the expected behavior
|
||||
* the current behavior and why you think it is a bug
|
||||
* what you've tried including the exact commands you were using or tasks you are running
|
||||
* any relevant configurations and the components you used
|
||||
* any relevant output plus ``ansible -vvvv`` (debugging) output
|
||||
* the steps to reproduce the bug
|
||||
* Use a minimal reproducible example and comments describing examples
|
||||
* Preserve formatting using `code blocks <https://help.github.com/articles/creating-and-highlighting-code-blocks/>`_ when sharing YAML in playbooks.
|
||||
* your Ansible version
|
||||
* the expected behavior and what you've tried, including the exact commands you were using or tasks you are running.
|
||||
* the current behavior and why you think it is a bug
|
||||
* the steps to reproduce the bug
|
||||
* a minimal reproducible example and comments describing examples
|
||||
* any relevant configurations and the components you used
|
||||
* any relevant output plus ``ansible -vvvv`` (debugging) output
|
||||
* add the output of ``ansible-test-env --show`` when filing bug reports involving ``ansible-test``.
|
||||
|
||||
For multiple-file content, use gist.github.com, which is more durable than pastebin content.
|
||||
When sharing YAML in playbooks, ensure that you preserve formatting using `code blocks <https://help.github.com/articles/creating-and-highlighting-code-blocks/>`_. For multiple-file content, use gist.github.com, more durable than Pastebin content.
|
||||
|
||||
.. _request_features:
|
||||
|
||||
|
||||
@ -53,12 +53,15 @@ The following table lists the current Steering Committee members. See :ref:`stee
|
||||
+------------------+---------------+-------------+
|
||||
| John Barker | gundalow | 2021 |
|
||||
+------------------+---------------+-------------+
|
||||
| Mario Lenz | mariolenz | 2022 |
|
||||
+------------------+---------------+-------------+
|
||||
| Markus Bergholz | markuman | 2022 |
|
||||
+------------------+---------------+-------------+
|
||||
| Sorin Sbarnea | ssbarnea | 2021 |
|
||||
+------------------+---------------+-------------+
|
||||
|
||||
|
||||
John Barker (`gundalow <https://github.com/gundalow>`_) has been elected by the Committee as its :ref:`chairperson`.
|
||||
|
||||
Committee members are selected based on their active contribution to the Ansible Project and its community. See :ref:`community_steering_guidelines` to learn details.
|
||||
|
||||
|
||||
@ -119,6 +119,8 @@ In case of the `Ansible Community Code of Conduct <https://docs.ansible.com/ansi
|
||||
|
||||
In case of starting the removal process, the topic's description in the reason's part changes correspondingly.
|
||||
|
||||
.. _chairperson:
|
||||
|
||||
Chairperson
|
||||
------------
|
||||
|
||||
|
||||
@ -70,7 +70,7 @@ The optional import behavior also applies to module_utils imported from collecti
|
||||
Listing collection dependencies
|
||||
===============================
|
||||
|
||||
We recommend that collections work as standalone, independent units, depending only on ansible-core. However, if your collection must depend on features and functionality from another collection, list the other collection or collections under ``dependencies`` in your collection's :file:`galaxy.yml` file. For more information on the :file:`galaxy.yml` file, see :ref:`collections_galaxy_meta`.
|
||||
We recommend that collections work as standalone, independent units, depending only on ansible-core. However, if your collection must depend on features and functionality from another collection, list the other collection or collections under ``dependencies`` in your collection's :file:`galaxy.yml` file. Use the :file:`meta/runtime.yml` file to set the ansible-core version that your collection depends on. For more information on the :file:`galaxy.yml` file, see :ref:`collections_galaxy_meta`.
|
||||
|
||||
You can use git repositories for collection dependencies during local development and testing. For example:
|
||||
|
||||
|
||||
@ -70,7 +70,9 @@ For community collections included in the Ansible PyPI package, docs.ansible.com
|
||||
toctree:
|
||||
- scenario_guide
|
||||
|
||||
The index page of the documentation for your collection displays the title you define in ``docs/docsite/extra-docs.yml`` with a link to your extra documentation. For an example, see the `community.docker collection repo <https://github.com/ansible-collections/community.docker/tree/main/docs/docsite>`_ and the `community.docker collection documentation <https://docs.ansible.com/ansible/latest/collections/community/docker/index.html>`_.
|
||||
The index page of the documentation for your collection displays the title you define in ``docs/docsite/extra-docs.yml`` with a link to your extra documentation. For an example, see the `community.docker collection repo <https://github.com/ansible-collections/community.docker/tree/main/docs/docsite>`_ and the `community.docker collection documentation <https://docs.ansible.com/ansible/latest/collections/community/docker/index.html>`_.
|
||||
|
||||
You can add extra links to your collection index page and plugin pages with the ``docs/docsite/links.yml`` file. This populates the links under `Description and Communications <https://docs.ansible.com/ansible/devel/collections/community/dns/index.html#plugins-in-community-dns>`_ headings as well as links at the end of the individual plugin pages. See the `collection_template links.yml file <https://github.com/ansible-collections/collection_template/blob/main/docs/docsite/links.yml>`_ for a complete description of the structure and use of this file to create links.
|
||||
|
||||
Plugin and module documentation
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
@ -196,8 +198,8 @@ When reading the :ref:`developing_testing` documentation, there will be content
|
||||
|
||||
.. _meta_runtime_yml:
|
||||
|
||||
meta directory
|
||||
--------------
|
||||
meta directory and runtime.yml
|
||||
------------------------------
|
||||
|
||||
A collection can store some additional metadata in a ``runtime.yml`` file in the collection's ``meta`` directory. The ``runtime.yml`` file supports the top level keys:
|
||||
|
||||
|
||||
@ -4,47 +4,31 @@
|
||||
Ansible and Python 3
|
||||
********************
|
||||
|
||||
The ``ansible-core`` code runs on both Python 2 and Python 3 because we want Ansible to be able to manage a wide
|
||||
variety of machines. Contributors to ansible-core and to Ansible Collections should be aware of the tips in this document so that they can write code that will run on the same versions of Python as the rest of Ansible.
|
||||
The ``ansible-core`` code runs Python 3 (for specific versions check `Control Node Requirements <:ref:control-node-requirements>`_.
|
||||
Contributors to ``ansible-core`` and to Ansible Collections should be aware of the tips in this document so that they can write code
|
||||
that will run on the same versions of Python as the rest of Ansible.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
||||
To ensure that your code runs on Python 3 as well as on Python 2, learn the tips and tricks and idioms
|
||||
described here. Most of these considerations apply to all three types of Ansible code:
|
||||
We do have some considerations depending on the types of Ansible code:
|
||||
|
||||
1. controller-side code - code that runs on the machine where you invoke :command:`/usr/bin/ansible`
|
||||
2. modules - the code which Ansible transmits to and invokes on the managed machine.
|
||||
3. shared ``module_utils`` code - the common code that's used by modules to perform tasks and sometimes used by controller-side code as well
|
||||
1. controller-side code - code that runs on the machine where you invoke :command:`/usr/bin/ansible`, only needs to support the controller's Python versions.
|
||||
2. modules - the code which Ansible transmits to and invokes on the managed machine. Modules need to support the 'managed node' Python versions, with some exceptions.
|
||||
3. shared ``module_utils`` code - the common code that is used by modules to perform tasks and sometimes used by controller-side code as well. Shared ``module_utils`` code needs to support the same range of Python as the modules.
|
||||
|
||||
However, the three types of code do not use the same string strategy. If you're developing a module or some ``module_utils`` code, be sure to read the section on string strategy carefully.
|
||||
|
||||
.. note:
|
||||
- While modules can be written in any language, the above applies to code contributed to the core project, which only supports specific Python versions and Powershell for Windows.
|
||||
|
||||
Minimum version of Python 3.x and Python 2.x
|
||||
============================================
|
||||
|
||||
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 `Control Node Requirements <:ref:control-node-requirements>`_ and `Managed Node Requirements <:ref:managed-node-requirements>`_ for the
|
||||
specific versions supported.
|
||||
|
||||
Python 3.5 was chosen as a minimum because it is the earliest Python 3 version adopted as the
|
||||
default Python by a Long Term Support (LTS) Linux distribution (in this case, Ubuntu-16.04).
|
||||
Previous LTS Linux distributions shipped with a Python 2 version which users can rely upon instead
|
||||
of the Python 3 version.
|
||||
|
||||
For Python 2, the default is for modules to run on at least Python 2.6. This allows
|
||||
users with older distributions that are stuck on Python 2.6 to manage their
|
||||
machines. Modules are allowed to drop support for Python 2.6 when one of
|
||||
their dependent libraries requires a higher version of Python. This is not an
|
||||
invitation to add unnecessary dependent libraries in order to force your
|
||||
module to be usable only with a newer version of Python; instead it is an
|
||||
acknowledgment that some libraries (for instance, boto3 and docker-py) will
|
||||
only function with a newer version of Python.
|
||||
|
||||
.. note:: Python 2.4 Module-side Support:
|
||||
|
||||
Support for Python 2.4 and Python 2.5 was dropped in Ansible-2.4. RHEL-5
|
||||
(and its rebuilds like CentOS-5) were supported until April of 2017.
|
||||
Ansible-2.3 was released in April of 2017 and was the last Ansible release
|
||||
to support Python 2.4 on the module-side.
|
||||
Your custom modules can support any version of Python (or other languages) you want, but the above are the requirements for the code contributed to the Ansible project.
|
||||
|
||||
Developing Ansible code that supports Python 2 and Python 3
|
||||
===========================================================
|
||||
@ -90,7 +74,7 @@ Ansible uses different strategies for working with strings in controller-side co
|
||||
Controller string strategy: the Unicode Sandwich
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
In controller-side code we use a strategy known as the Unicode Sandwich (named
|
||||
Until recently ``ansible-core`` supported Python 2.x and followed this strategy, known as the Unicode Sandwich (named
|
||||
after Python 2's :func:`unicode <python:unicode>` text type). For Unicode Sandwich we know that
|
||||
at the border of our code and the outside world (for example, file and network IO,
|
||||
environment variables, and some library calls) we are going to receive bytes.
|
||||
@ -100,6 +84,13 @@ the outside world we first convert the text back into bytes.
|
||||
To visualize this, imagine a 'sandwich' consisting of a top and bottom layer
|
||||
of bytes, a layer of conversion between, and all text type in the center.
|
||||
|
||||
For compatibility reasons you will see a bunch of custom functions we developed (``to_text``/``to_bytes``/``to_native``)
|
||||
and while Python 2 is not a concern anymore we will continue to use them as they apply for other cases that make
|
||||
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.
|
||||
|
||||
Unicode Sandwich common borders: places to convert bytes to text in controller code
|
||||
-----------------------------------------------------------------------------------
|
||||
|
||||
@ -400,8 +391,3 @@ does have support for the older, percent-formatting.
|
||||
Python documentation on `percent formatting <https://docs.python.org/3/library/stdtypes.html#string-formatting>`_
|
||||
|
||||
.. _testing_modules_python_3:
|
||||
|
||||
Testing modules on Python 3
|
||||
===================================
|
||||
|
||||
Ansible modules are slightly harder to code to support Python 3 than normal code from other projects. A lot of mocking has to go into unit testing an Ansible module, so it's harder to test that your changes have fixed everything or to to make sure that later commits haven't regressed the Python 3 support. Review our :ref:`testing <developing_testing>` pages for more information.
|
||||
|
||||
@ -127,22 +127,28 @@ Networking
|
||||
|
||||
No notable changes
|
||||
|
||||
Porting Guide for v5.6.0
|
||||
========================
|
||||
|
||||
Added Collections
|
||||
-----------------
|
||||
|
||||
- community.sap (version 1.0.0)
|
||||
|
||||
Deprecated Features
|
||||
-------------------
|
||||
|
||||
cisco.ios
|
||||
~~~~~~~~~
|
||||
|
||||
- Deprecates lldp module.
|
||||
|
||||
Porting Guide for v5.5.0
|
||||
========================
|
||||
|
||||
Known Issues
|
||||
------------
|
||||
|
||||
cisco.ios
|
||||
~~~~~~~~~
|
||||
|
||||
- `ios_bgp_global` - Added capability of configure network options.
|
||||
- `ios_bgp_global` - Added community and local_preference for route_reflector_client.
|
||||
- `ios_bgp_global` - Added update_source for neighbors.
|
||||
- `ios_bgp_global` - Correct misspelled attributes with alternates/alias.
|
||||
- `ios_bgp_global` - Facts and config code optimized for using rm_templates.
|
||||
- `ios_bgp_global` - Parsers added for non-implemented attributes.
|
||||
|
||||
community.general
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
484
docs/docsite/rst/porting_guides/porting_guide_6.rst
Normal file
484
docs/docsite/rst/porting_guides/porting_guide_6.rst
Normal file
@ -0,0 +1,484 @@
|
||||
..
|
||||
THIS DOCUMENT IS AUTOMATICALLY GENERATED BY ANTSIBULL! PLEASE DO NOT EDIT MANUALLY! (YOU PROBABLY WANT TO EDIT porting_guide_core_2.13.rst)
|
||||
|
||||
.. _porting_6_guide:
|
||||
|
||||
=======================
|
||||
Ansible 6 Porting Guide
|
||||
=======================
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
:depth: 2
|
||||
|
||||
|
||||
Ansible 6 is based on Ansible-core 2.13.
|
||||
|
||||
|
||||
We suggest you read this page along with the `Ansible 6 Changelog <https://github.com/ansible-community/ansible-build-data/blob/main/6/CHANGELOG-v6.rst>`_ to understand what updates you may need to make.
|
||||
|
||||
|
||||
Playbook
|
||||
========
|
||||
|
||||
* Templating - You can no longer perform arithmetic and concatenation operations outside of the jinja template. The following statement will need to be rewritten to produce ``[1, 2]``:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
- name: Prior to 2.13
|
||||
debug:
|
||||
msg: '[1] + {{ [2] }}'
|
||||
|
||||
- name: 2.13 and forward
|
||||
debug:
|
||||
msg: '{{ [1] + [2] }}'
|
||||
|
||||
* The return value of the ``__repr__`` method of an undefined variable represented by the ``AnsibleUndefined`` object changed. ``{{ '%r'|format(undefined_variable) }}`` returns ``AnsibleUndefined(hint=None, obj=missing, name='undefined_variable')`` in 2.13 as opposed to just ``AnsibleUndefined`` in versions 2.12 and prior.
|
||||
|
||||
* The ``finalize`` method is no longer exposed in the globals for use in templating. To convert ``None`` to an empty string the following expression can be used: ``{{ value if value is not none }}``.
|
||||
|
||||
|
||||
Command Line
|
||||
============
|
||||
|
||||
No notable changes
|
||||
|
||||
|
||||
Deprecated
|
||||
==========
|
||||
|
||||
No notable changes
|
||||
|
||||
|
||||
Modules
|
||||
=======
|
||||
|
||||
* To use ansible-core 2.13 for module execution, you must use Python 2 version 2.7 or Python 3 version 3.5 or newer. Any code utilizing ``ansible.module_utils.basic`` will not function with lower Python versions.
|
||||
|
||||
|
||||
Modules removed
|
||||
---------------
|
||||
|
||||
The following modules no longer exist:
|
||||
|
||||
* No notable changes
|
||||
|
||||
|
||||
Deprecation notices
|
||||
-------------------
|
||||
|
||||
No notable changes
|
||||
|
||||
|
||||
Noteworthy module changes
|
||||
-------------------------
|
||||
|
||||
No notable changes
|
||||
|
||||
|
||||
Breaking Changes
|
||||
----------------
|
||||
|
||||
* ``ansible.module_utils.urls.fetch_url`` will now return the captured ``HTTPError`` exception as ``r``. ``HTTPError`` is a response like object that can offer more information to module authors. Modules should rely on ``info['status'] >= 400`` to determine if there was a failure, instead of using ``r is None`` or catching ``AttributeError`` when attempting ``r.read()``.
|
||||
|
||||
|
||||
Plugins
|
||||
=======
|
||||
|
||||
No notable changes
|
||||
|
||||
|
||||
Porting custom scripts
|
||||
======================
|
||||
|
||||
No notable changes
|
||||
|
||||
|
||||
Networking
|
||||
==========
|
||||
|
||||
No notable changes
|
||||
|
||||
Porting Guide for v6.0.0a1
|
||||
==========================
|
||||
|
||||
Added Collections
|
||||
-----------------
|
||||
|
||||
- community.sap (version 1.0.0)
|
||||
|
||||
Known Issues
|
||||
------------
|
||||
|
||||
Ansible-core
|
||||
~~~~~~~~~~~~
|
||||
|
||||
- get_url - document ``check_mode`` correctly with unreliable changed status (https://github.com/ansible/ansible/issues/65687).
|
||||
|
||||
community.general
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
- pacman - ``update_cache`` cannot differentiate between up to date and outdated package lists and will report ``changed`` in both situations (https://github.com/ansible-collections/community.general/pull/4318).
|
||||
- pacman - binaries specified in the ``executable`` parameter must support ``--print-format`` in order to be used by this module. In particular, AUR helper ``yay`` is known not to currently support it (https://github.com/ansible-collections/community.general/pull/4312).
|
||||
|
||||
dellemc.openmanage
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- idrac_user - Issue(192043) The module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again.
|
||||
- ome_application_alerts_smtp - Issue(212310) - The module does not provide a proper error message if the destination_address is more than 255 characters.
|
||||
- ome_application_alerts_syslog - Issue(215374) - The module does not provide a proper error message if the destination_address is more than 255 characters.
|
||||
- ome_application_console_preferences - Issue(224690) - The module does not display a proper error message when an unsupported value is provided for the parameters report_row_limit, email_sender_settings, and metric_collection_settings, and the value is applied on OpenManage Enterprise.
|
||||
- ome_device_local_access_configuration - Issue(215035) - The module reports ``Successfully updated the local access setting`` if an unsupported value is provided for the parameter timeout_limit. However, this value is not actually applied on OpenManage Enterprise Modular.
|
||||
- ome_device_local_access_configuration - Issue(217865) - The module does not display a proper error message if an unsupported value is provided for the user_defined and lcd_language parameters.
|
||||
- ome_device_network_services - Issue(212681) - The module does not provide a proper error message if unsupported values are provided for the parameters- port_number, community_name, max_sessions, max_auth_retries, and idle_timeout.
|
||||
- ome_device_power_settings - Issue(212679) - The module displays the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.``
|
||||
- ome_device_power_settings - Issue(212679) - The module errors out with the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.``
|
||||
- ome_device_power_settings - Issue(212679) - The module errors out with the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.``
|
||||
- ome_device_quick_deploy - Issue(216352) - The module does not display a proper error message if an unsupported value is provided for the ipv6_prefix_length and vlan_id parameters.
|
||||
- ome_smart_fabric_uplink - Issue(186024) - The module does not allow the creation of multiple uplinks of the same name even though it is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified.
|
||||
|
||||
purestorage.flasharray
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- purefa_admin - Once `max_login` and `lockout` have been set there is currently no way to rest these to zero except through the FlashArray GUI
|
||||
|
||||
Breaking Changes
|
||||
----------------
|
||||
|
||||
Ansible-core
|
||||
~~~~~~~~~~~~
|
||||
|
||||
- Module Python Dependency - Drop support for Python 2.6 in module execution.
|
||||
- Templating - it is no longer allowed to perform arithmetic and concatenation operations outside of the jinja template (https://github.com/ansible/ansible/pull/75587)
|
||||
- The ``finalize`` method is no longer exposed in the globals for use in templating.
|
||||
|
||||
amazon.aws
|
||||
~~~~~~~~~~
|
||||
|
||||
- aws_caller_facts - Remove deprecated ``aws_caller_facts`` alias. Please use ``aws_caller_info`` instead.
|
||||
- cloudformation_facts - Remove deprecated ``cloudformation_facts`` alias. Please use ``cloudformation_info`` instead.
|
||||
- ec2_ami_facts - Remove deprecated ``ec2_ami_facts`` alias. Please use ``ec2_ami_info`` instead.
|
||||
- ec2_eni_facts - Remove deprecated ``ec2_eni_facts`` alias. Please use ``ec2_eni_info`` instead.
|
||||
- ec2_group_facts - Remove deprecated ``ec2_group_facts`` alias. Please use ``ec2_group_info`` instead.
|
||||
- ec2_instance_facts - Remove deprecated ``ec2_instance_facts`` alias. Please use ``ec2_instance_info`` instead.
|
||||
- ec2_snapshot_facts - Remove deprecated ``ec2_snapshot_facts`` alias. Please use ``ec2_snapshot_info`` instead.
|
||||
- ec2_vol_facts - Remove deprecated ``ec2_vol_facts`` alias. Please use ``ec2_vol_info`` instead.
|
||||
- ec2_vpc_dhcp_option_facts - Remove deprecated ``ec2_vpc_dhcp_option_facts`` alias. Please use ``ec2_vpc_dhcp_option_info`` instead.
|
||||
- ec2_vpc_endpoint_facts - Remove deprecated ``ec2_vpc_endpoint_facts`` alias. Please use ``ec2_vpc_endpoint_info`` instead.
|
||||
- ec2_vpc_igw_facts - Remove deprecated ``ec2_vpc_igw_facts`` alias. Please use ``ec2_vpc_igw_info`` instead.
|
||||
- ec2_vpc_nat_gateway_facts - Remove deprecated ``ec2_vpc_nat_gateway_facts`` alias. Please use ``ec2_vpc_nat_gateway_info`` instead.
|
||||
- ec2_vpc_net_facts - Remove deprecated ``ec2_vpc_net_facts`` alias. Please use ``ec2_vpc_net_info`` instead.
|
||||
- ec2_vpc_route_table_facts - Remove deprecated ``ec2_vpc_route_table_facts`` alias. Please use ``ec2_vpc_route_table_info`` instead.
|
||||
- ec2_vpc_subnet_facts - Remove deprecated ``ec2_vpc_subnet_facts`` alias. Please use ``ec2_vpc_subnet_info`` instead.
|
||||
|
||||
arista.eos
|
||||
~~~~~~~~~~
|
||||
|
||||
- eos_command - new suboption ``version`` of parameter ``command``, which controls the JSON response version. Previously the value was assumed to be "latest" for network_cli and "1" for httpapi, but the default will now be "latest" for both connections. This option is also available for use in modules making their own device requests with ``plugins.module_utils.network.eos.eos.run_commands()`` with the same new default behavior. (https://github.com/ansible-collections/arista.eos/pull/258).
|
||||
|
||||
community.aws
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
- aws_acm_facts - Remove deprecated alias ``aws_acm_facts``. Please use ``aws_acm_info`` instead.
|
||||
- aws_kms_facts - Remove deprecated alias ``aws_kms_facts``. Please use ``aws_kms_info`` instead.
|
||||
- aws_kms_info - Deprecated ``keys_attr`` field is now ignored (https://github.com/ansible-collections/community.aws/pull/838).
|
||||
- aws_region_facts - Remove deprecated alias ``aws_region_facts``. Please use ``aws_region_info`` instead.
|
||||
- aws_s3_bucket_facts - Remove deprecated alias ``aws_s3_bucket_facts``. Please use ``aws_s3_bucket_info`` instead.
|
||||
- aws_sgw_facts - Remove deprecated alias ``aws_sgw_facts``. Please use ``aws_sgw_info`` instead.
|
||||
- aws_waf_facts - Remove deprecated alias ``aws_waf_facts``. Please use ``aws_waf_info`` instead.
|
||||
- cloudfront_facts - Remove deprecated alias ``cloudfront_facts``. Please use ``cloudfront_info`` instead.
|
||||
- cloudwatchlogs_log_group_facts - Remove deprecated alias ``cloudwatchlogs_log_group_facts``. Please use ``cloudwatchlogs_log_group_info`` instead.
|
||||
- dynamodb_table - deprecated updates currently ignored for primary keys and global_all indexes will now result in a failure. (https://github.com/ansible-collections/community.aws/pull/837).
|
||||
- ec2_asg_facts - Remove deprecated alias ``ec2_asg_facts``. Please use ``ec2_asg_info`` instead.
|
||||
- ec2_customer_gateway_facts - Remove deprecated alias ``ec2_customer_gateway_facts``. Please use ``ec2_customer_gateway_info`` instead.
|
||||
- ec2_eip_facts - Remove deprecated alias ``ec2_eip_facts``. Please use ``ec2_eip_info`` instead.
|
||||
- ec2_elb_facts - Remove deprecated alias ``ec2_elb_facts``. Please use ``ec2_elb_info`` instead.
|
||||
- ec2_elb_info - The ``ec2_elb_info`` module has been removed. Please use ``the ``elb_classic_lb_info`` module.
|
||||
- ec2_lc_facts - Remove deprecated alias ``ec2_lc_facts``. Please use ``ec2_lc_info`` instead.
|
||||
- ec2_placement_group_facts - Remove deprecated alias ``ec2_placement_group_facts``. Please use ``ec2_placement_group_info`` instead.
|
||||
- ec2_vpc_nacl_facts - Remove deprecated alias ``ec2_vpc_nacl_facts``. Please use ``ec2_vpc_nacl_info`` instead.
|
||||
- ec2_vpc_peering_facts - Remove deprecated alias ``ec2_vpc_peering_facts``. Please use ``ec2_vpc_peering_info`` instead.
|
||||
- ec2_vpc_route_table_facts - Remove deprecated alias ``ec2_vpc_route_table_facts``. Please use ``ec2_vpc_route_table_info`` instead.
|
||||
- ec2_vpc_vgw_facts - Remove deprecated alias ``ec2_vpc_vgw_facts``. Please use ``ec2_vpc_vgw_info`` instead.
|
||||
- ec2_vpc_vpn_facts - Remove deprecated alias ``ec2_vpc_vpn_facts``. Please use ``ec2_vpc_vpn_info`` instead.
|
||||
- ecs_service_facts - Remove deprecated alias ``ecs_service_facts``. Please use ``ecs_service_info`` instead.
|
||||
- ecs_taskdefinition_facts - Remove deprecated alias ``ecs_taskdefinition_facts``. Please use ``ecs_taskdefinition_info`` instead.
|
||||
- efs_facts - Remove deprecated alias ``efs_facts``. Please use ``efs_info`` instead.
|
||||
- elasticache_facts - Remove deprecated alias ``elasticache_facts``. Please use ``elasticache_info`` instead.
|
||||
- elb_application_lb_facts - Remove deprecated alias ``elb_application_lb_facts``. Please use ``elb_application_lb_info`` instead.
|
||||
- elb_classic_lb_facts - Remove deprecated alias ``elb_classic_lb_facts``. Please use ``elb_classic_lb_info`` instead.
|
||||
- elb_target_facts - Remove deprecated alias ``elb_target_facts``. Please use ``elb_target_info`` instead.
|
||||
- elb_target_group_facts - Remove deprecated alias ``elb_target_group_facts``. Please use ``elb_target_group_info`` instead.
|
||||
- iam - Removed deprecated ``community.aws.iam`` module. Please use ``community.aws.iam_user``, ``community.aws.iam_access_key`` or ``community.aws.iam_group`` (https://github.com/ansible-collections/community.aws/pull/839).
|
||||
- iam_cert_facts - Remove deprecated alias ``iam_cert_facts``. Please use ``iam_cert_info`` instead.
|
||||
- iam_mfa_device_facts - Remove deprecated alias ``iam_mfa_device_facts``. Please use ``iam_mfa_device_info`` instead.
|
||||
- iam_role_facts - Remove deprecated alias ``iam_role_facts``. Please use ``iam_role_info`` instead.
|
||||
- iam_server_certificate_facts - Remove deprecated alias ``iam_server_certificate_facts``. Please use ``iam_server_certificate_info`` instead.
|
||||
- lambda_facts - Remove deprecated module lambda_facts``. Please use ``lambda_info`` instead.
|
||||
- rds - Removed deprecated ``community.aws.rds`` module. Please use ``community.aws.rds_instance`` (https://github.com/ansible-collections/community.aws/pull/839).
|
||||
- rds_instance_facts - Remove deprecated alias ``rds_instance_facts``. Please use ``rds_instance_info`` instead.
|
||||
- rds_snapshot_facts - Remove deprecated alias ``rds_snapshot_facts``. Please use ``rds_snapshot_info`` instead.
|
||||
- redshift_facts - Remove deprecated alias ``redshift_facts``. Please use ``redshift_info`` instead.
|
||||
- route53_facts - Remove deprecated alias ``route53_facts``. Please use ``route53_info`` instead.
|
||||
|
||||
community.mysql
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
- mysql_replication - remove ``Is_Slave`` and ``Is_Master`` return values (were replaced with ``Is_Primary`` and ``Is_Replica`` (https://github.com/ansible-collections /community.mysql/issues/145).
|
||||
- mysql_replication - remove the mode options values containing ``master``/``slave`` and the master_use_gtid option ``slave_pos`` (were replaced with corresponding ``primary``/``replica`` values) (https://github.com/ansible-collections/community.mysql/issues/145).
|
||||
- mysql_user - remove support for the `REQUIRESSL` special privilege as it has ben superseded by the `tls_requires` option (https://github.com/ansible-collections/community.mysql/discussions/121).
|
||||
- mysql_user - validate privileges using database engine directly (https://github.com/ansible-collections/community.mysql/issues/234 https://github.com/ansible-collections/community.mysql/pull/243). Do not validate privileges in this module anymore.
|
||||
|
||||
community.vmware
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
- The collection now requires at least ansible-core 2.11.0. Ansible 3 and before, and ansible-base versions are no longer supported.
|
||||
- vmware_cluster_drs - The default for ``enable`` has been changed from ``false`` to ``true``.
|
||||
- vmware_cluster_drs - The parameter alias ``enable_drs`` has been removed, use ``enable`` instead.
|
||||
- vmware_cluster_ha - The default for ``enable`` has been changed from ``false`` to ``true``.
|
||||
- vmware_cluster_ha - The parameter alias ``enable_ha`` has been removed, use ``enable`` instead.
|
||||
- vmware_cluster_vsan - The default for ``enable`` has been changed from ``false`` to ``true``.
|
||||
- vmware_cluster_vsan - The parameter alias ``enable_vsan`` has been removed, use ``enable`` instead.
|
||||
- vmware_guest - Virtualization Based Security has some requirements (``nested_virt``, ``secure_boot`` and ``iommu``) that the module silently enabled. They have to be enabled explicitly now.
|
||||
|
||||
dellemc.openmanage
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- HTTPS SSL certificate validation is a **breaking change** and will require modification in the existing playbooks. Please refer to `SSL Certificate Validation <https://github.com/dell/dellemc-openmanage-ansible-modules#ssl-certificate-validation>`_ section in the `README.md <https://github.com/dell/dellemc-openmanage-ansible-modules/blob/collections/README.md#SSL-Certificate-Validation>`_ for modification to existing playbooks.
|
||||
|
||||
theforeman.foreman
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- Set use_reports_api default value to true for the inventory plugin
|
||||
- Support for Ansible 2.8 is removed
|
||||
|
||||
Major Changes
|
||||
-------------
|
||||
|
||||
Ansible-core
|
||||
~~~~~~~~~~~~
|
||||
|
||||
- Jinja2 Controller Requirement - Jinja2 3.0.0 or newer is required for the control node (the machine that runs Ansible) (https://github.com/ansible/ansible/pull/75881)
|
||||
- Templating - remove ``safe_eval`` in favor of using ``NativeEnvironment`` but utilizing ``literal_eval`` only in cases when ``safe_eval`` was used (https://github.com/ansible/ansible/pull/75587)
|
||||
|
||||
amazon.aws
|
||||
~~~~~~~~~~
|
||||
|
||||
- amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.19.0`` and ``boto3<1.16.0``. Most modules will continue to work with older versions of the AWS SDK, however compatability with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/574).
|
||||
|
||||
chocolatey.chocolatey
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- win_chocolatey - Added choco_args option to pass additional arguments directly to Chocolatey.
|
||||
|
||||
cisco.ise
|
||||
~~~~~~~~~
|
||||
|
||||
- Update ciscoisesdk requirement to 1.2.0
|
||||
- anc_endpoint_bulk_monitor_status_info - change return value, it returns BulkStatus content.
|
||||
- anc_policy_bulk_monitor_status_info - change return value, it returns BulkStatus content.
|
||||
- backup_last_status_info - change return value, it returns response content.
|
||||
- device_administration_authentication_rules - deletes parameter identitySourceId.
|
||||
- device_administration_authentication_rules_info - change return value, it returns response content.
|
||||
- device_administration_authorization_rules_info - change return value, it returns response content.
|
||||
- device_administration_conditions - deletes parameter attributeId.
|
||||
- device_administration_conditions_for_authentication_rule_info - change return value, it returns response content.
|
||||
- device_administration_conditions_for_authorization_rule_info - change return value, it returns response content.
|
||||
- device_administration_conditions_for_policy_set_info - change return value, it returns response content.
|
||||
- device_administration_conditions_info - change return value, it returns response content.
|
||||
- device_administration_dictionary_attributes_authentication_info - change return value, it returns response content.
|
||||
- device_administration_dictionary_attributes_authorization_info - change return value, it returns response content.
|
||||
- device_administration_dictionary_attributes_policy_set_info - change return value, it returns response content.
|
||||
- device_administration_global_exception_rules_info - change return value, it returns response content.
|
||||
- device_administration_network_conditions_info - change return value, it returns response content.
|
||||
- device_administration_time_date_conditions - deletes parameter attributeId.
|
||||
- device_administration_time_date_conditions_info - change return value, it returns response content.
|
||||
- egress_matrix_cell_bulk_monitor_status_info - change return value, it returns BulkStatus content.
|
||||
- network_access_authentication_rules - deletes parameter identitySourceId.
|
||||
- network_access_conditions - deletes parameter attributeId.
|
||||
- network_access_time_date_conditions - deletes parameter attributeId.
|
||||
- node_deployment - update parameters.
|
||||
- node_deployment_info - add filter and filterType parameters.
|
||||
- node_group - fixes response recollection.
|
||||
- node_group_info - fixes response recollection.
|
||||
- repository_files_info - change return value, it returns response content.
|
||||
- repository_info - change return value, it returns response content.
|
||||
- sg_acl_bulk_monitor_status_info - change return value, it returns BulkStatus content.
|
||||
- sg_mapping_bulk_monitor_status_info - change return value, it returns BulkStatus content.
|
||||
- sg_mapping_group_bulk_monitor_status_info - change return value, it returns BulkStatus content.
|
||||
- sg_mapping_group_info - change return value, it returns BulkStatus content.
|
||||
- sg_to_vn_to_vlan_bulk_monitor_status_info - change return value, it returns BulkStatus content.
|
||||
- sgt - change generationId type from int to str.
|
||||
- sgt_bulk_monitor_status_info - change return value, it returns BulkStatus content.
|
||||
- sxp_connections_bulk_monitor_status_info - change return value, it returns BulkStatus content.
|
||||
- sxp_local_bindings_bulk_monitor_status_info - change return value, it returns BulkStatus content.
|
||||
- sxp_vpns_bulk_monitor_status_info - change return value, it returns BulkStatus content.
|
||||
- system_certificate - new parameters portalTagTransferForSameSubject and roleTransferForSameSubject.
|
||||
- system_certificate - portalTagTransferForSameSubject parameter renamed to allowPortalTagTransferForSameSubject.
|
||||
- system_certificate - roleTransferForSameSubject parameter renamed to allowRoleTransferForSameSubject.
|
||||
- system_certificate_import - new parameters portalTagTransferForSameSubject and roleTransferForSameSubject.
|
||||
- system_certificate_import - portalTagTransferForSameSubject parameter renamed to allowPortalTagTransferForSameSubject.
|
||||
- system_certificate_import - roleTransferForSameSubject parameter renamed to allowRoleTransferForSameSubject.
|
||||
- trustsec_nbar_app_info - change type from str to list.
|
||||
- trustsec_vn_info - change type from str to list.
|
||||
|
||||
cisco.meraki
|
||||
~~~~~~~~~~~~
|
||||
|
||||
- meraki_mr_radio - New module
|
||||
|
||||
community.aws
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
- community.aws collection - The community.aws collection has dropped support for ``botocore<1.19.0`` and ``boto3<1.16.0``. Most modules will continue to work with older versions of the AWS SDK, however compatability with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/community.aws/pull/809).
|
||||
- s3_bucket_notifications - refactor module to support SNS / SQS targets as well as the existing support for Lambda functions (https://github.com/ansible-collections/community.aws/issues/140).
|
||||
|
||||
community.postgresql
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- postgresql_privs - the ``usage_on_types`` feature have been deprecated and will be removed in ``community.postgresql 3.0.0``. Please use the ``type`` option with the ``type`` value to explicitly grant/revoke privileges on types (https://github.com/ansible-collections/community.postgresql/issues/207).
|
||||
- postgresql_query - the ``path_to_script`` and ``as_single_query`` options as well as the ``query_list`` and ``query_all_results`` return values have been deprecated and will be removed in ``community.postgresql 3.0.0``. Please use the ``community.postgresql.postgresql_script`` module to execute statements from scripts (https://github.com/ansible-collections/community.postgresql/issues/189).
|
||||
- postgresql_query - the default value of the ``as_single_query`` option changes to ``yes``. If the related behavior of your tasks where the module is involved changes, please adjust the parameter's value correspondingly (https://github.com/ansible-collections/community.postgresql/issues/85).
|
||||
- postgresql_user - the ``priv`` argument has been deprecated and will be removed in ``community.postgresql 3.0.0``. Please use the ``postgresql_privs`` module to grant/revoke privileges instead (https://github.com/ansible-collections/community.postgresql/issues/212).
|
||||
|
||||
containers.podman
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
- Add podman_tag module
|
||||
- Add secrets driver and driver opts support
|
||||
|
||||
dellemc.openmanage
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- All modules can read custom or organizational CA signed certificate from the environment variables. Please refer to `SSL Certificate Validation <https://github.com/dell/dellemc-openmanage-ansible-modules#ssl-certificate-validation>`_ section in the `README.md <https://github.com/dell/dellemc-openmanage-ansible-modules/blob/collections/README.md#SSL-Certificate-Validation>`_ for modification to existing playbooks or setting environment variable.
|
||||
- All modules now support SSL over HTTPS and socket level timeout.
|
||||
|
||||
f5networks.f5_modules
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- bigip_device_info - pagination logic has also been added to help with api stability.
|
||||
- bigip_device_info - the module no longer gathers information from all partitions on device. This change will stabalize the module by gathering resources only from the given partition and prevent the module from gathering way too much information that might result in crashing.
|
||||
|
||||
ovirt.ovirt
|
||||
~~~~~~~~~~~
|
||||
|
||||
- manageiq - role removed (https://github.com/oVirt/ovirt-ansible-collection/pull/375).
|
||||
|
||||
vyos.vyos
|
||||
~~~~~~~~~
|
||||
|
||||
- Add 'pool' as value to server key in ntp_global.
|
||||
|
||||
Removed Features
|
||||
----------------
|
||||
|
||||
Ansible-core
|
||||
~~~~~~~~~~~~
|
||||
|
||||
- Remove deprecated ``Templar.set_available_variables()`` method (https://github.com/ansible/ansible/issues/75828)
|
||||
- cli - remove deprecated ability to set verbosity before the sub-command (https://github.com/ansible/ansible/issues/75823)
|
||||
- copy - remove deprecated ``thirsty`` alias (https://github.com/ansible/ansible/issues/75824)
|
||||
- psrp - Removed fallback on ``put_file`` with older ``pypsrp`` versions. Users must have at least ``pypsrp>=0.4.0``.
|
||||
- url_argument_spec - remove deprecated ``thirsty`` alias for ``get_url`` and ``uri`` modules (https://github.com/ansible/ansible/issues/75825, https://github.com/ansible/ansible/issues/75826)
|
||||
|
||||
community.hashi_vault
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- the "legacy" integration test setup has been removed; this does not affect end users and is only relevant to contributors (https://github.com/ansible-collections/community.hashi_vault/pull/191).
|
||||
|
||||
community.vmware
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
- vcenter_extension_facts - The deprecated module ``vcenter_extension_facts`` has been removed, use ``vcenter_extension_info`` instead.
|
||||
- vmware_about_facts - The deprecated module ``vmware_about_facts`` has been removed, use ``vmware_about_info`` instead.
|
||||
- vmware_category_facts - The deprecated module ``vmware_category_facts`` has been removed, use ``vmware_category_info`` instead.
|
||||
- vmware_cluster - Remove DRS configuration in favour of module ``vmware_cluster_drs``.
|
||||
- vmware_cluster - Remove HA configuration in favour of module ``vmware_cluster_ha``.
|
||||
- vmware_cluster - Remove VSAN configuration in favour of module ``vmware_cluster_vsan``.
|
||||
- vmware_cluster_facts - The deprecated module ``vmware_cluster_facts`` has been removed, use ``vmware_cluster_info`` instead.
|
||||
- vmware_datastore_facts - The deprecated module ``vmware_datastore_facts`` has been removed, use ``vmware_datastore_info`` instead.
|
||||
- vmware_drs_group_facts - The deprecated module ``vmware_drs_group_facts`` has been removed, use ``vmware_drs_group_info`` instead.
|
||||
- vmware_drs_rule_facts - The deprecated module ``vmware_drs_rule_facts`` has been removed, use ``vmware_drs_rule_info`` instead.
|
||||
- vmware_dvs_portgroup - The deprecated parameter ``portgroup_type`` has been removed, use ``port_binding`` instead.
|
||||
- vmware_dvs_portgroup_facts - The deprecated module ``vmware_dvs_portgroup_facts`` has been removed, use ``vmware_dvs_portgroup_info`` instead.
|
||||
- vmware_guest_boot_facts - The deprecated module ``vmware_guest_boot_facts`` has been removed, use ``vmware_guest_boot_info`` instead.
|
||||
- vmware_guest_customization_facts - The deprecated module ``vmware_guest_customization_facts`` has been removed, use ``vmware_guest_customization_info`` instead.
|
||||
- vmware_guest_disk_facts - The deprecated module ``vmware_guest_disk_facts`` has been removed, use ``vmware_guest_disk_info`` instead.
|
||||
- vmware_guest_facts - The deprecated module ``vmware_guest_facts`` has been removed, use ``vmware_guest_info`` instead.
|
||||
- vmware_guest_snapshot_facts - The deprecated module ``vmware_guest_snapshot_facts`` has been removed, use ``vmware_guest_snapshot_info`` instead.
|
||||
- vmware_host_capability_facts - The deprecated module ``vmware_host_capability_facts`` has been removed, use ``vmware_host_capability_info`` instead.
|
||||
- vmware_host_config_facts - The deprecated module ``vmware_host_config_facts`` has been removed, use ``vmware_host_config_info`` instead.
|
||||
- vmware_host_dns_facts - The deprecated module ``vmware_host_dns_facts`` has been removed, use ``vmware_host_dns_info`` instead.
|
||||
- vmware_host_feature_facts - The deprecated module ``vmware_host_feature_facts`` has been removed, use ``vmware_host_feature_info`` instead.
|
||||
- vmware_host_firewall_facts - The deprecated module ``vmware_host_firewall_facts`` has been removed, use ``vmware_host_firewall_info`` instead.
|
||||
- vmware_host_ntp_facts - The deprecated module ``vmware_host_ntp_facts`` has been removed, use ``vmware_host_ntp_info`` instead.
|
||||
- vmware_host_package_facts - The deprecated module ``vmware_host_package_facts`` has been removed, use ``vmware_host_package_info`` instead.
|
||||
- vmware_host_service_facts - The deprecated module ``vmware_host_service_facts`` has been removed, use ``vmware_host_service_info`` instead.
|
||||
- vmware_host_ssl_facts - The deprecated module ``vmware_host_ssl_facts`` has been removed, use ``vmware_host_ssl_info`` instead.
|
||||
- vmware_host_vmhba_facts - The deprecated module ``vmware_host_vmhba_facts`` has been removed, use ``vmware_host_vmhba_info`` instead.
|
||||
- vmware_host_vmnic_facts - The deprecated module ``vmware_host_vmnic_facts`` has been removed, use ``vmware_host_vmnic_info`` instead.
|
||||
- vmware_local_role_facts - The deprecated module ``vmware_local_role_facts`` has been removed, use ``vmware_local_role_info`` instead.
|
||||
- vmware_local_user_facts - The deprecated module ``vmware_local_user_facts`` has been removed, use ``vmware_local_user_info`` instead.
|
||||
- vmware_portgroup_facts - The deprecated module ``vmware_portgroup_facts`` has been removed, use ``vmware_portgroup_info`` instead.
|
||||
- vmware_resource_pool_facts - The deprecated module ``vmware_resource_pool_facts`` has been removed, use ``vmware_resource_pool_info`` instead.
|
||||
- vmware_tag_facts - The deprecated module ``vmware_tag_facts`` has been removed, use ``vmware_tag_info`` instead.
|
||||
- vmware_target_canonical_facts - The deprecated module ``vmware_target_canonical_facts`` has been removed, use ``vmware_target_canonical_info`` instead.
|
||||
- vmware_vm_facts - The deprecated module ``vmware_vm_facts`` has been removed, use ``vmware_vm_info`` instead.
|
||||
- vmware_vmkernel_facts - The deprecated module ``vmware_vmkernel_facts`` has been removed, use ``vmware_vmkernel_info`` instead.
|
||||
- vmware_vmkernel_ip_config - The deprecated module ``vmware_vmkernel_ip_config`` has been removed, use ``vmware_vmkernel`` instead.
|
||||
- vmware_vswitch_facts - The deprecated module ``vmware_vswitch_facts`` has been removed, use ``vmware_vswitch_info`` instead.
|
||||
|
||||
Deprecated Features
|
||||
-------------------
|
||||
|
||||
Ansible-core
|
||||
~~~~~~~~~~~~
|
||||
|
||||
- ansible-core - Remove support for Python 2.6.
|
||||
- ansible-test - Remove support for Python 2.6.
|
||||
- ssh connection plugin option scp_if_ssh in favor of ssh_transfer_method.
|
||||
|
||||
amazon.aws
|
||||
~~~~~~~~~~
|
||||
|
||||
- ec2_instance - The default value for ```instance_type``` has been deprecated, in the future release you must set an instance_type or a launch_template (https://github.com/ansible-collections/amazon.aws/pull/587).
|
||||
- module_utils - support for the original AWS SDK `boto` has been deprecated in favour of the `boto3`/`botocore` SDK. All `boto` based modules have either been deprecated or migrated to `botocore`, and the remaining support code in module_utils will be removed in release 4.0.0 of the amazon.aws collection. Any modules outside of the amazon.aws and community.aws collections based on the `boto` library will need to be migrated to the `boto3`/`botocore` libraries (https://github.com/ansible-collections/amazon.aws/pull/575).
|
||||
|
||||
cisco.ios
|
||||
~~~~~~~~~
|
||||
|
||||
- Deprecates lldp module.
|
||||
- `ios_acls` - Deprecated fragment attribute added boolean alternate as enable_fragment.
|
||||
|
||||
cisco.nxos
|
||||
~~~~~~~~~~
|
||||
|
||||
- Deprecated nxos_snmp_community module.
|
||||
- Deprecated nxos_snmp_contact module.
|
||||
- Deprecated nxos_snmp_host module.
|
||||
- Deprecated nxos_snmp_location module.
|
||||
- Deprecated nxos_snmp_traps module.
|
||||
- Deprecated nxos_snmp_user module.
|
||||
|
||||
community.general
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
- mail callback plugin - not specifying ``sender`` is deprecated and will be disallowed in community.general 6.0.0 (https://github.com/ansible-collections/community.general/pull/4140).
|
||||
- module_helper module utils - deprecated the attribute ``ModuleHelper.VarDict`` (https://github.com/ansible-collections/community.general/pull/3801).
|
||||
- pacman - from community.general 5.0.0 on, the ``changed`` status of ``update_cache`` will no longer be ignored if ``name`` or ``upgrade`` is specified. To keep the old behavior, add something like ``register: result`` and ``changed_when: result.packages | length > 0`` to your task (https://github.com/ansible-collections/community.general/pull/4329).
|
||||
|
||||
community.hashi_vault
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.hashi_vault 3.0.0) next spring (https://github.com/ansible-community/community-topics/issues/50, https://github.com/ansible-collections/community.hashi_vault/issues/189).
|
||||
- aws_iam_login auth method - the ``aws_iam_login`` method has been renamed to ``aws_iam``. The old name will be removed in collection version ``3.0.0``. Until then both names will work, and a warning will be displayed when using the old name (https://github.com/ansible-collections/community.hashi_vault/pull/193).
|
||||
|
||||
junipernetworks.junos
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- 'router_id' options is deprecated from junos_ospf_interfaces, junos_ospfv2 and junos_ospfv3 resuorce module.
|
||||
|
||||
purestorage.flasharray
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- purefa_sso - Deprecated in favor of M(purefa_admin). Will be removed in Collection 2.0
|
||||
@ -10,6 +10,7 @@ This section lists porting guides that can help you in updating playbooks, plugi
|
||||
:maxdepth: 1
|
||||
:glob:
|
||||
|
||||
porting_guide_6
|
||||
porting_guide_5
|
||||
porting_guide_4
|
||||
porting_guide_3
|
||||
|
||||
@ -16,9 +16,9 @@ Ansible can also install a collection collected with ``ansible-galaxy collection
|
||||
.. code-block:: yaml
|
||||
|
||||
collections:
|
||||
- source: /tmp/my_namespace-my_collection-1.0.0.tar.gz
|
||||
- name: /tmp/my_namespace-my_collection-1.0.0.tar.gz
|
||||
type: file
|
||||
|
||||
.. note::
|
||||
|
||||
Relative paths are calculated from the current working directory (where you are invoking ``ansible-galaxy install -r`` from). They are not taken relative to the ``requirements.yml`` file.
|
||||
Relative paths are calculated from the current working directory (where you are invoking ``ansible-galaxy install -r`` from). They are not taken relative to the ``requirements.yml`` file.
|
||||
|
||||
31
docs/docsite/rst/user_guide/cheatsheet.rst
Normal file
31
docs/docsite/rst/user_guide/cheatsheet.rst
Normal file
@ -0,0 +1,31 @@
|
||||
.. _cheatsheet:
|
||||
|
||||
**********************
|
||||
Ansible CLI cheatsheet
|
||||
**********************
|
||||
|
||||
This page shows one or more examples of each Ansible command line utility with some common flags added and a link to the full documentation for the command. This page offers a quick reminder of some common use cases only - it may be out of date or incomplete or both. For canonical documentation, follow the links to the CLI pages.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
||||
ansible-playbook
|
||||
================
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-playbook -i /path/to/my_inventory_file -u my_connection_user -k /path/to/my_ssh_key -f 3 -T 30 -t my_tag -m /path/to/my_modules -b -K my_playbook.yml
|
||||
|
||||
Loads ``my_playbook.yml`` from the current working directory and:
|
||||
- ``-i`` - uses ``my_inventory_file`` in the path provided for :ref:`inventory <intro_inventory>` to match the :ref:`pattern <intro_patterns>`.
|
||||
- ``-u`` - connects :ref:`over SSH <connections>` as ``my_connection_user``.
|
||||
- ``-k`` - uses ``my_ssh_key`` in the path provided for SSH authentication.
|
||||
- ``-f`` - allocates 3 :ref:`forks <playbooks_strategies>`.
|
||||
- ``-T`` - sets a 30-second timeout.
|
||||
- ``-t`` - runs only tasks marked with the :ref:`tag <tags>` ``my_tag``.
|
||||
- ``-m`` - loads :ref:`local modules <developing_locally>` from ``/path/to/my/modules``.
|
||||
- ``-b`` - executes with elevated privileges (uses :ref:`become <become>`).
|
||||
- ``-K`` - prompts the user for the become password.
|
||||
|
||||
See :ref:`ansible-playbook` for detailed documentation.
|
||||
|
||||
@ -273,12 +273,14 @@ You can even combine these simple examples with other filters and lookups to cre
|
||||
:caption: Using 'vars' to define dictionary from a set of lists without needing a task
|
||||
|
||||
vars:
|
||||
myvarnames: "{{ q('varnames', '^my') }}"
|
||||
mydict: "{{ dict(myvarnames | zip(q('vars', *myvarnames))) }}"
|
||||
xyz_stuff: 1234
|
||||
xyz_morestuff: 567
|
||||
myvarnames: "{{ q('varnames', '^xyz_') }}"
|
||||
mydict: "{{ dict(myvarnames|map('regex_replace', '^xyz_', '')|list | zip(q('vars', *myvarnames))) }}"
|
||||
|
||||
A quick explanation, since there is a lot to unpack from these two lines:
|
||||
|
||||
- The ``varnames`` lookup returns a list of variables that match "begin with ``my``".
|
||||
- The ``varnames`` lookup returns a list of variables that match "begin with ``xyz_``".
|
||||
- Then feeding the list from the previous step into the ``vars`` lookup to get the list of values.
|
||||
The ``*`` is used to 'dereference the list' (a pythonism that works in Jinja), otherwise it would take the list as a single argument.
|
||||
- Both lists get passed to the ``zip`` filter to pair them off into a unified list (key, value, key2, value2, ...).
|
||||
|
||||
@ -22,6 +22,7 @@ Getting started
|
||||
|
||||
* I'm ready to learn about Ansible. What :ref:`basic_concepts` do I need to learn?
|
||||
* I want to use Ansible without writing a playbook. How do I use :ref:`ad hoc commands <intro_adhoc>`?
|
||||
* I'm running an Ansible command and forgot which flags to use. Do you have a :ref:`cheatsheet`?
|
||||
|
||||
Writing tasks, plays, and playbooks
|
||||
===================================
|
||||
@ -91,6 +92,7 @@ If you prefer to read the entire User Guide, here's a list of the pages in order
|
||||
:maxdepth: 2
|
||||
|
||||
quickstart
|
||||
cheatsheet
|
||||
basic_concepts
|
||||
intro_getting_started
|
||||
intro_adhoc
|
||||
|
||||
@ -274,8 +274,8 @@ In the above example, running Ansible against the host alias "jumper" will conne
|
||||
.. note::
|
||||
Values passed in the INI format using the ``key=value`` syntax are interpreted differently depending on where they are declared:
|
||||
|
||||
* When declared inline with the host, INI values are interpreted as Python literal structures (strings, numbers, tuples, lists, dicts, booleans, None). Host lines accept multiple ``key=value`` parameters per line. Therefore they need a way to indicate that a space is part of a value rather than a separator.
|
||||
|
||||
* When declared inline with the host, INI values are interpreted as Python literal structures (strings, numbers, tuples, lists, dicts, booleans, None). Host lines accept multiple ``key=value`` parameters per line. Therefore they need a way to indicate that a space is part of a value rather than a separator. Values that contain whitespace can be quoted (single or double). See the `Python shlex parsing rules`_ for details.
|
||||
|
||||
* When declared in a ``:vars`` section, INI values are interpreted as strings. For example ``var=FALSE`` would create a string equal to 'FALSE'. Unlike host lines, ``:vars`` sections accept only a single entry per line, so everything after the ``=`` must be the value for the entry.
|
||||
|
||||
* If a variable value set in an INI inventory must be a certain type (for example, a string or a boolean value), always specify the type with a filter in your task. Do not rely on types set in INI inventories when consuming variables.
|
||||
@ -284,6 +284,8 @@ In the above example, running Ansible against the host alias "jumper" will conne
|
||||
|
||||
Generally speaking, this is not the best way to define variables that describe your system policy. Setting variables in the main inventory file is only a shorthand. See :ref:`splitting_out_vars` for guidelines on storing variable values in individual files in the 'host_vars' directory.
|
||||
|
||||
.. _Python shlex parsing rules: https://docs.python.org/3/library/shlex.html#parsing-rules
|
||||
|
||||
.. _group_variables:
|
||||
|
||||
Assigning a variable to many machines: group variables
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
Handlers: running operations on change
|
||||
======================================
|
||||
|
||||
Sometimes you want a task to run only when a change is made on a machine. For example, you may want to restart a service if a task updates the configuration of that service, but not if the configuration is unchanged. Ansible uses handlers to address this use case. Handlers are tasks that only run when notified. Each handler should have a globally unique name.
|
||||
Sometimes you want a task to run only when a change is made on a machine. For example, you may want to restart a service if a task updates the configuration of that service, but not if the configuration is unchanged. Ansible uses handlers to address this use case. Handlers are tasks that only run when notified.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
@ -46,7 +46,13 @@ This playbook, ``verify-apache.yml``, contains a single play with a handler.
|
||||
name: httpd
|
||||
state: restarted
|
||||
|
||||
In this example playbook, the second task notifies the handler. A single task can notify more than one handler:
|
||||
In this example playbook, the Apache server is restarted by the handler after all tasks complete in the play.
|
||||
|
||||
|
||||
Notifying handlers
|
||||
------------------
|
||||
|
||||
Tasks can instruct one or more handlers to execute using the ``notify`` keyword. The ``notify`` keyword can be applied to a task and accepts a list of handler names that are notified on a task change. Alternately, a string containing a single handler name can be supplied as well. The following example demonstrates how multiple handlers can be notified by a single task:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -56,8 +62,8 @@ In this example playbook, the second task notifies the handler. A single task ca
|
||||
src: template.j2
|
||||
dest: /etc/foo.conf
|
||||
notify:
|
||||
- Restart memcached
|
||||
- Restart apache
|
||||
- Restart memcached
|
||||
|
||||
handlers:
|
||||
- name: Restart memcached
|
||||
@ -70,12 +76,51 @@ In this example playbook, the second task notifies the handler. A single task ca
|
||||
name: apache
|
||||
state: restarted
|
||||
|
||||
In the above example the handlers are executed on task change in the following order: ``Restart memcached``, ``Restart apache``. Handlers are executed in the order they are defined in the ``handlers`` section, not in the order listed in the ``notify`` statement. Notifying the same handler multiple times will result in executing the handler only once regardless of how many tasks notify it. For example, if multiple tasks update a configuration file and notify a handler to restart Apache, Ansible only bounces Apache once to avoid unnecessary restarts.
|
||||
|
||||
|
||||
Naming handlers
|
||||
---------------
|
||||
|
||||
Handlers must be named in order for tasks to be able to notify them using the ``notify`` keyword.
|
||||
|
||||
Alternately, handlers can utilize the ``listen`` keyword. Using this handler keyword, handlers can listen on topics that can group multiple handlers as follows:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
tasks:
|
||||
- name: Restart everything
|
||||
command: echo "this task will restart the web services"
|
||||
notify: "restart web services"
|
||||
|
||||
handlers:
|
||||
- name: Restart memcached
|
||||
service:
|
||||
name: memcached
|
||||
state: restarted
|
||||
listen: "restart web services"
|
||||
|
||||
- name: Restart apache
|
||||
service:
|
||||
name: apache
|
||||
state: restarted
|
||||
listen: "restart web services"
|
||||
|
||||
Notifying the ``restart web services`` topic results in executing all handlers listening to that topic regardless of how those handlers are named.
|
||||
|
||||
This use makes it much easier to trigger multiple handlers. It also decouples handlers from their names, making it easier to share handlers among playbooks and roles (especially when using third-party roles from a shared source such as Ansible Galaxy).
|
||||
|
||||
Each handler should have a globally unique name. If multiple handlers are defined with the same name, only the last one defined is notified with ``notify``, effectively shadowing all of the previous handlers with the same name. Alternately handlers sharing the same name can all be notified and executed if they listen on the same topic by notifying that topic.
|
||||
|
||||
There is only one global scope for handlers (handler names and listen topics) regardless of where the handlers are defined. This also includes handlers defined in roles.
|
||||
|
||||
|
||||
Controlling when handlers run
|
||||
-----------------------------
|
||||
|
||||
By default, handlers run after all the tasks in a particular play have been completed. This approach is efficient, because the handler only runs once, regardless of how many tasks notify it. For example, if multiple tasks update a configuration file and notify a handler to restart Apache, Ansible only bounces Apache once to avoid unnecessary restarts.
|
||||
By default, handlers run after all the tasks in a particular play have been completed. Notified handlers are executed automatically after each of the following sections, in the following order: ``pre_tasks``, ``roles``/``tasks`` and ``post_tasks``. This approach is efficient, because the handler only runs once, regardless of how many tasks notify it. For example, if multiple tasks update a configuration file and notify a handler to restart Apache, Ansible only bounces Apache once to avoid unnecessary restarts.
|
||||
|
||||
If you need handlers to run before the end of the play, add a task to flush them using the :ref:`meta module <meta_module>`, which executes Ansible actions.
|
||||
If you need handlers to run before the end of the play, add a task to flush them using the :ref:`meta module <meta_module>`, which executes Ansible actions:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -91,10 +136,15 @@ If you need handlers to run before the end of the play, add a task to flush them
|
||||
|
||||
The ``meta: flush_handlers`` task triggers any handlers that have been notified at that point in the play.
|
||||
|
||||
Once handlers are executed, either automatically after each mentioned section or manually by the ``flush_handlers`` meta task, they can be notified and run again in later sections of the play.
|
||||
|
||||
|
||||
Using variables with handlers
|
||||
-----------------------------
|
||||
|
||||
You may want your Ansible handlers to use variables. For example, if the name of a service varies slightly by distribution, you want your output to show the exact name of the restarted service for each target machine. Avoid placing variables in the name of the handler. Since handler names are templated early on, Ansible may not have a value available for a handler name like this::
|
||||
You may want your Ansible handlers to use variables. For example, if the name of a service varies slightly by distribution, you want your output to show the exact name of the restarted service for each target machine. Avoid placing variables in the name of the handler. Since handler names are templated early on, Ansible may not have a value available for a handler name like this:
|
||||
|
||||
.. code-block:: yaml+jinja
|
||||
|
||||
handlers:
|
||||
# This handler name may cause your play to fail!
|
||||
@ -104,7 +154,7 @@ If the variable used in the handler name is not available, the entire play fails
|
||||
|
||||
Instead, place variables in the task parameters of your handler. You can load the values using ``include_vars`` like this:
|
||||
|
||||
.. code-block:: yaml+jinja
|
||||
.. code-block:: yaml+jinja
|
||||
|
||||
tasks:
|
||||
- name: Set host variables based on distribution
|
||||
@ -116,44 +166,25 @@ Instead, place variables in the task parameters of your handler. You can load th
|
||||
name: "{{ web_service_name | default('httpd') }}"
|
||||
state: restarted
|
||||
|
||||
Handlers can also "listen" to generic topics, and tasks can notify those topics as follows:
|
||||
|
||||
.. code-block:: yaml
|
||||
While handler names can contain a template, ``listen`` topics cannot.
|
||||
|
||||
|
||||
handlers:
|
||||
- name: Restart memcached
|
||||
ansible.builtin.service:
|
||||
name: memcached
|
||||
state: restarted
|
||||
listen: "restart web services"
|
||||
Handlers in roles
|
||||
-----------------
|
||||
|
||||
- name: Restart apache
|
||||
ansible.builtin.service:
|
||||
name: apache
|
||||
state: restarted
|
||||
listen: "restart web services"
|
||||
Handlers from roles are not just contained in their roles but rather inserted into global scope with all other handlers from a play. As such they can be used outside of the role they are defined in. It also means that their name can conflict with handlers from outside the role. To ensure that a handler from a role is notified as opposed to one from outside the role with the same name, notify the handler by using its name in the following form: ``role_name : handler_name``.
|
||||
|
||||
tasks:
|
||||
- name: Restart everything
|
||||
ansible.builtin.command: echo "this task will restart the web services"
|
||||
notify: "restart web services"
|
||||
Handlers notified within the ``roles`` section are automatically flushed at the end of the ``tasks`` section, but before any ``tasks`` handlers.
|
||||
|
||||
This use makes it much easier to trigger multiple handlers. It also decouples handlers from their names,
|
||||
making it easier to share handlers among playbooks and roles (especially when using 3rd party roles from
|
||||
a shared source like Galaxy).
|
||||
|
||||
.. note::
|
||||
* Handlers always run in the order they are defined, not in the order listed in the notify-statement. This is also the case for handlers using `listen`.
|
||||
* Handler names and `listen` topics live in a global namespace.
|
||||
* Handler names are templatable and `listen` topics are not.
|
||||
* Use unique handler names. If you trigger more than one handler with the same name, the first one(s) get overwritten. Only the last one defined will run.
|
||||
* You can notify a handler defined inside a static include.
|
||||
* You cannot notify a handler defined inside a dynamic include.
|
||||
* A handler can not run import_role or include_role.
|
||||
Includes and imports in handlers
|
||||
--------------------------------
|
||||
Notifying a dynamic include such as ``include_task`` as a handler results in executing all tasks from within the include. It is not possible to notify a handler defined inside a dynamic include.
|
||||
|
||||
When using handlers within roles, note that:
|
||||
Having a static include such as ``import_task`` as a handler results in that handler being effectively rewritten by handlers from within that import before the play execution. A static include itself cannot be notified, the tasks from withing that include, on the other hand, can be notified individually.
|
||||
|
||||
* handlers notified within ``pre_tasks``, ``tasks``, and ``post_tasks`` sections are automatically flushed at the end of section where they were notified.
|
||||
* handlers notified within ``roles`` section are automatically flushed at the end of ``tasks`` section, but before any ``tasks`` handlers.
|
||||
* handlers are play scoped and as such can be used outside of the role they are defined in.
|
||||
|
||||
Limitations
|
||||
-----------
|
||||
|
||||
A handler cannot run ``import_role`` or ``include_role``.
|
||||
|
||||
@ -406,7 +406,7 @@ Passing different parameters
|
||||
|
||||
If you pass different parameters in each role definition, Ansible runs the role more than once. Providing different variable values is not the same as passing different role parameters. You must use the ``roles`` keyword for this behavior, since ``import_role`` and ``include_role`` do not accept role parameters.
|
||||
|
||||
This playbook runs the ``foo`` role twice:
|
||||
This play runs the ``foo`` role twice:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
||||
@ -101,7 +101,7 @@ To create a vault password client script:
|
||||
* Within the script itself:
|
||||
* Print the passwords to standard output
|
||||
* Accept a ``--vault-id`` option
|
||||
* If the script prompts for data (for example, a database password), send the prompts to standard error
|
||||
* If the script prompts for data (for example, a database password), display the prompts to the TTY.
|
||||
|
||||
When you run a playbook that uses vault passwords stored in a third-party tool, specify the script as the source within the ``--vault-id`` flag. For example:
|
||||
|
||||
|
||||
@ -12,7 +12,7 @@ is the same as Ansible, it is just executed in a different manner. Since
|
||||
Ansible 2.4, the ``win_dsc`` module has been added and can be used to take advantage of
|
||||
existing DSC resources when interacting with a Windows host.
|
||||
|
||||
More details on DSC can be viewed at `DSC Overview <https://docs.microsoft.com/en-us/powershell/scripting/dsc/overview/overview>`_.
|
||||
More details on DSC can be viewed at `DSC Overview <https://docs.microsoft.com/en-us/powershell/scripting/dsc/overview?view=powershell-7.2>`_.
|
||||
|
||||
Host Requirements
|
||||
`````````````````
|
||||
@ -33,7 +33,7 @@ on the scenario.
|
||||
Reasons for using an Ansible module over a DSC resource:
|
||||
|
||||
* The host does not support PowerShell v5.0, or it cannot easily be upgraded
|
||||
* The DSC resource does not offer a feature present in an Ansible module. For example
|
||||
* The DSC resource does not offer a feature present in an Ansible module. For example,
|
||||
win_regedit can manage the ``REG_NONE`` property type, while the DSC
|
||||
``Registry`` resource cannot
|
||||
* DSC resources have limited check mode support, while some Ansible modules have
|
||||
@ -57,7 +57,7 @@ and it does the job, just use DSC for that task.
|
||||
How to Use DSC?
|
||||
```````````````
|
||||
The ``win_dsc`` module takes in a free-form of options so that it changes
|
||||
according to the resource it is managing. A list of built in resources can be
|
||||
according to the resource it is managing. A list of built-in resources can be
|
||||
found at `resources <https://docs.microsoft.com/en-us/powershell/scripting/dsc/resources/resources>`_.
|
||||
|
||||
Using the `Registry <https://docs.microsoft.com/en-us/powershell/scripting/dsc/reference/resources/windows/registryresource>`_
|
||||
@ -78,7 +78,7 @@ resource as an example, this is the DSC definition as documented by Microsoft:
|
||||
}
|
||||
|
||||
When defining the task, ``resource_name`` must be set to the DSC resource being
|
||||
used - in this case the ``resource_name`` should be set to ``Registry``. The
|
||||
used - in this case, the ``resource_name`` should be set to ``Registry``. The
|
||||
``module_version`` can refer to a specific version of the DSC resource
|
||||
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
|
||||
@ -154,10 +154,10 @@ invocation output for the above ``Registry`` task:
|
||||
}
|
||||
|
||||
The ``invocation.module_args`` key shows the actual values that were set as
|
||||
well as other possible values that were not set. Unfortunately this will not
|
||||
well as other possible values that were not set. Unfortunately, this will not
|
||||
show the default value for a DSC property, only what was set from the Ansible
|
||||
task. Any ``*_password`` option will be masked in the output for security
|
||||
reasons, if there are any other sensitive module options, set ``no_log: True``
|
||||
reasons; if there are any other sensitive module options, set ``no_log: True``
|
||||
on the task to stop all task output from being logged.
|
||||
|
||||
|
||||
@ -165,8 +165,8 @@ Property Types
|
||||
--------------
|
||||
Each DSC resource property has a type that is associated with it. Ansible
|
||||
will try to convert the defined options to the correct type during execution.
|
||||
For simple types like ``[string]`` and ``[bool]`` this is a simple operation,
|
||||
but complex types like ``[PSCredential]`` or arrays (like ``[string[]]``) this
|
||||
For simple types like ``[string]`` and ``[bool]``, this is a simple operation,
|
||||
but complex types like ``[PSCredential]`` or arrays (like ``[string[]]``)
|
||||
require certain rules.
|
||||
|
||||
PSCredential
|
||||
@ -174,7 +174,7 @@ PSCredential
|
||||
A ``[PSCredential]`` object is used to store credentials in a secure way, but
|
||||
Ansible has no way to serialize this over JSON. To set a DSC PSCredential property,
|
||||
the definition of that parameter should have two entries that are suffixed with
|
||||
``_username`` and ``_password`` for the username and password respectively.
|
||||
``_username`` and ``_password`` for the username and password, respectively.
|
||||
For example:
|
||||
|
||||
.. code-block:: yaml+jinja
|
||||
@ -219,14 +219,14 @@ class definition is typically located in the ``<resource name>.schema.mof``.
|
||||
HashTable Type
|
||||
++++++++++++++
|
||||
A ``[HashTable]`` object is also a dictionary but does not have a strict set of
|
||||
keys that can/need to be defined. Like a ``[CimInstance]``, define it like a
|
||||
keys that can/need to be defined. Like a ``[CimInstance]``, define it as a
|
||||
normal dictionary value in YAML. A ``[HashTable]]`` is defined with
|
||||
``EmbeddedInstance("MSFT_KeyValuePair")`` in a DSC resource MOF definition.
|
||||
|
||||
Arrays
|
||||
++++++
|
||||
Simple type arrays like ``[string[]]`` or ``[UInt32[]]`` are defined as a list
|
||||
or as a comma separated string which are then cast to their type. Using a list
|
||||
or as a comma-separated string which is then cast to their type. Using a list
|
||||
is recommended because the values are not manually parsed by the ``win_dsc``
|
||||
module before being passed to the DSC engine. For example, to define a simple
|
||||
type array in Ansible:
|
||||
@ -264,7 +264,7 @@ like this example:
|
||||
Port: 80
|
||||
IPAddress: '*'
|
||||
|
||||
The above example, is an array with two values of the class `MSFT_xWebBindingInformation <https://github.com/dsccommunity/xWebAdministration/blob/master/source/DSCResources/MSFT_xWebSite/MSFT_xWebSite.schema.mof>`_.
|
||||
The above example is an array with two values of the class `MSFT_xWebBindingInformation <https://github.com/dsccommunity/xWebAdministration/blob/master/source/DSCResources/MSFT_xWebSite/MSFT_xWebSite.schema.mof>`_.
|
||||
When defining a ``[CimInstance[]]``, be sure to read the resource documentation
|
||||
to find out what keys to use in the definition.
|
||||
|
||||
@ -293,10 +293,10 @@ All the values above are equal to a UTC date time of February 22nd 2019 at
|
||||
Run As Another User
|
||||
-------------------
|
||||
By default, DSC runs each resource as the SYSTEM account and not the account
|
||||
that Ansible use to run the module. This means that resources that are dynamically
|
||||
that Ansible uses to run the module. This means that resources that are dynamically
|
||||
loaded based on a user profile, like the ``HKEY_CURRENT_USER`` registry hive,
|
||||
will be loaded under the ``SYSTEM`` profile. The parameter
|
||||
``PsDscRunAsCredential`` is a parameter that can be set for every DSC resource
|
||||
``PsDscRunAsCredential`` is a parameter that can be set for every DSC resource, and
|
||||
force the DSC engine to run under a different account. As
|
||||
``PsDscRunAsCredential`` has a type of ``PSCredential``, it is defined with the
|
||||
``_username`` and ``_password`` suffix.
|
||||
@ -337,7 +337,7 @@ The ``Find-DscResource`` cmdlet can also be used to find custom resources. For e
|
||||
# Find all DSC resources that relate to SQL
|
||||
Find-DscResource -ModuleName "*sql*"
|
||||
|
||||
.. Note:: DSC resources developed by Microsoft that start with ``x``, means the
|
||||
.. Note:: DSC resources developed by Microsoft that start with ``x`` means the
|
||||
resource is experimental and comes with no support.
|
||||
|
||||
Installing a Custom Resource
|
||||
@ -346,9 +346,9 @@ There are three ways that a DSC resource can be installed on a host:
|
||||
|
||||
* Manually with the ``Install-Module`` cmdlet
|
||||
* Using the ``win_psmodule`` Ansible module
|
||||
* Saving the module manually and copying it another host
|
||||
* Saving the module manually and copying it to another host
|
||||
|
||||
This is an example of installing the ``xWebAdministration`` resources using
|
||||
The following is an example of installing the ``xWebAdministration`` resources using
|
||||
``win_psmodule``:
|
||||
|
||||
.. code-block:: yaml+jinja
|
||||
@ -371,10 +371,10 @@ can be run:
|
||||
|
||||
Save-Module -Name xWebAdministration -Path C:\temp
|
||||
|
||||
This will create a folder called ``xWebAdministration`` in ``C:\temp`` which
|
||||
This will create a folder called ``xWebAdministration`` in ``C:\temp``, which
|
||||
can be copied to any host. For PowerShell to see this offline resource, it must
|
||||
be copied to a directory set in the ``PSModulePath`` environment variable.
|
||||
In most cases the path ``C:\Program Files\WindowsPowerShell\Module`` is set
|
||||
In most cases, the path ``C:\Program Files\WindowsPowerShell\Module`` is set
|
||||
through this variable, but the ``win_path`` module can be used to add different
|
||||
paths.
|
||||
|
||||
|
||||
@ -111,6 +111,9 @@ exclude_patterns = [
|
||||
'community/reporting_collections.rst',
|
||||
'community/contributing_maintained_collections.rst',
|
||||
'community/collection_development_process.rst',
|
||||
'community/collection_contributors/collection_release_without_branches.rst',
|
||||
'community/collection_contributors/collection_release_with_branches.rst',
|
||||
'community/collection_contributors/collection_releasing.rst',
|
||||
'community/maintainers_guidelines.rst',
|
||||
'community/maintainers_workflow.rst',
|
||||
'community/steering/community_steering_committee.rst',
|
||||
|
||||
@ -13,7 +13,7 @@ import pathlib
|
||||
import yaml
|
||||
from ansible.module_utils.six import string_types
|
||||
from ansible.module_utils._text import to_bytes
|
||||
from antsibull.jinja2.environment import doc_environment
|
||||
from antsibull_docs.jinja2.environment import doc_environment
|
||||
|
||||
# Pylint doesn't understand Python3 namespace modules.
|
||||
from ..change_detection import update_file_if_different # pylint: disable=relative-beyond-top-level
|
||||
|
||||
@ -102,7 +102,7 @@ def find_latest_deps_file(build_data_working, ansible_version):
|
||||
def generate_base_docs(args):
|
||||
"""Regenerate the documentation for all plugins listed in the plugin_to_collection_file."""
|
||||
# imports here so that they don't cause unnecessary deps for all of the plugins
|
||||
from antsibull.cli import antsibull_docs
|
||||
from antsibull_docs.cli import antsibull_docs
|
||||
|
||||
with TemporaryDirectory() as tmp_dir:
|
||||
#
|
||||
@ -135,7 +135,7 @@ def generate_full_docs(args):
|
||||
"""Regenerate the documentation for all plugins listed in the plugin_to_collection_file."""
|
||||
# imports here so that they don't cause unnecessary deps for all of the plugins
|
||||
import sh
|
||||
from antsibull.cli import antsibull_docs
|
||||
from antsibull_docs.cli import antsibull_docs
|
||||
|
||||
with TemporaryDirectory() as tmp_dir:
|
||||
sh.git(['clone', 'https://github.com/ansible-community/ansible-build-data'], _cwd=tmp_dir)
|
||||
|
||||
@ -1571,7 +1571,6 @@ INTERPRETER_PYTHON_FALLBACK:
|
||||
- /usr/bin/python3
|
||||
- /usr/libexec/platform-python
|
||||
- python2.7
|
||||
- python2.6
|
||||
- /usr/bin/python
|
||||
- python
|
||||
vars:
|
||||
|
||||
@ -30,6 +30,7 @@ from ansible.galaxy import get_collections_galaxy_meta_info
|
||||
from ansible.galaxy.dependency_resolution.dataclasses import _GALAXY_YAML
|
||||
from ansible.galaxy.user_agent import user_agent
|
||||
from ansible.module_utils._text import to_bytes, to_native, to_text
|
||||
from ansible.module_utils.common.process import get_bin_path
|
||||
from ansible.module_utils.common.yaml import yaml_load
|
||||
from ansible.module_utils.six import raise_from
|
||||
from ansible.module_utils.urls import open_url
|
||||
@ -393,11 +394,19 @@ def _extract_collection_from_git(repo_url, coll_ver, b_path):
|
||||
prefix=to_bytes(name, errors='surrogate_or_strict'),
|
||||
) # type: bytes
|
||||
|
||||
try:
|
||||
git_executable = get_bin_path('git')
|
||||
except ValueError as err:
|
||||
raise AnsibleError(
|
||||
"Could not find git executable to extract the collection from the Git repository `{repo_url!s}`.".
|
||||
format(repo_url=to_native(git_url))
|
||||
) from err
|
||||
|
||||
# Perform a shallow clone if simply cloning HEAD
|
||||
if version == 'HEAD':
|
||||
git_clone_cmd = 'git', 'clone', '--depth=1', git_url, to_text(b_checkout_path)
|
||||
git_clone_cmd = git_executable, 'clone', '--depth=1', git_url, to_text(b_checkout_path)
|
||||
else:
|
||||
git_clone_cmd = 'git', 'clone', git_url, to_text(b_checkout_path)
|
||||
git_clone_cmd = git_executable, 'clone', git_url, to_text(b_checkout_path)
|
||||
# FIXME: '--branch', version
|
||||
|
||||
try:
|
||||
@ -411,7 +420,7 @@ def _extract_collection_from_git(repo_url, coll_ver, b_path):
|
||||
proc_err,
|
||||
)
|
||||
|
||||
git_switch_cmd = 'git', 'checkout', to_text(version)
|
||||
git_switch_cmd = git_executable, 'checkout', to_text(version)
|
||||
try:
|
||||
subprocess.check_call(git_switch_cmd, cwd=b_checkout_path)
|
||||
except subprocess.CalledProcessError as proc_err:
|
||||
|
||||
@ -502,6 +502,7 @@ class AnsibleModule(object):
|
||||
self.validation_result = self.validator.validate(self.params)
|
||||
self.params.update(self.validation_result.validated_parameters)
|
||||
self.no_log_values.update(self.validation_result._no_log_values)
|
||||
self.aliases.update(self.validation_result._aliases)
|
||||
|
||||
try:
|
||||
error = self.validation_result.errors[0]
|
||||
|
||||
@ -61,6 +61,7 @@ class ValidationResult:
|
||||
self._validated_parameters = deepcopy(parameters)
|
||||
self._deprecations = []
|
||||
self._warnings = []
|
||||
self._aliases = {}
|
||||
self.errors = AnsibleValidationErrorMultiple()
|
||||
"""
|
||||
:class:`~ansible.module_utils.errors.AnsibleValidationErrorMultiple` containing all
|
||||
@ -180,12 +181,11 @@ class ArgumentSpecValidator:
|
||||
alias_warnings = []
|
||||
alias_deprecations = []
|
||||
try:
|
||||
aliases = _handle_aliases(self.argument_spec, result._validated_parameters, alias_warnings, alias_deprecations)
|
||||
result._aliases.update(_handle_aliases(self.argument_spec, result._validated_parameters, alias_warnings, alias_deprecations))
|
||||
except (TypeError, ValueError) as e:
|
||||
aliases = {}
|
||||
result.errors.append(AliasError(to_native(e)))
|
||||
|
||||
legal_inputs = _get_legal_inputs(self.argument_spec, result._validated_parameters, aliases)
|
||||
legal_inputs = _get_legal_inputs(self.argument_spec, result._validated_parameters, result._aliases)
|
||||
|
||||
for option, alias in alias_warnings:
|
||||
result._warnings.append({'option': option, 'alias': alias})
|
||||
|
||||
@ -27,7 +27,7 @@ if HAS_YAML:
|
||||
from yaml.cyaml import CParser as Parser
|
||||
|
||||
HAS_LIBYAML = True
|
||||
except AttributeError:
|
||||
except (ImportError, AttributeError):
|
||||
from yaml import SafeLoader # type: ignore[misc]
|
||||
from yaml import SafeDumper # type: ignore[misc]
|
||||
from yaml.parser import Parser # type: ignore[misc]
|
||||
|
||||
@ -61,8 +61,10 @@ options:
|
||||
version_added: "2.12"
|
||||
ssh_opts:
|
||||
description:
|
||||
- Options git will pass to ssh when used as protocol, it works via GIT_SSH_OPTIONS.
|
||||
- For older versions it appends GIT_SSH_OPTIONS to GIT_SSH/GIT_SSH_COMMAND.
|
||||
- Options git will pass to ssh when used as protocol, it works via C(git)'s
|
||||
GIT_SSH/GIT_SSH_COMMAND environment variables.
|
||||
- For older versions it appends GIT_SSH_OPTS (specific to this module) to the
|
||||
variables above or via a wrapper script.
|
||||
- Other options can add to this list, like I(key_file) and I(accept_hostkey).
|
||||
- An example value could be "-o StrictHostKeyChecking=no" (although this particular
|
||||
option is better set by I(accept_hostkey)).
|
||||
@ -441,7 +443,7 @@ def write_ssh_wrapper(module):
|
||||
|
||||
# use existing git_ssh/ssh_command, fallback to 'ssh'
|
||||
template = b("""#!/bin/sh
|
||||
%s $GIT_SSH_OPTS
|
||||
%s $GIT_SSH_OPTS "$@"
|
||||
""" % os.environ.get('GIT_SSH', os.environ.get('GIT_SSH_COMMAND', 'ssh')))
|
||||
|
||||
# write it
|
||||
@ -484,27 +486,33 @@ def set_git_ssh_env(key_file, ssh_opts, git_version, module):
|
||||
|
||||
# deal with key file
|
||||
if key_file:
|
||||
os.environ["GIT_KEY"] = key_file
|
||||
key_opt = '-i %s' % key_file
|
||||
if key_opt not in ssh_opts:
|
||||
ssh_opts += ' %s' % key_opt
|
||||
|
||||
ikey = 'IdentitiesOnly=yes'
|
||||
if ikey not in ssh_opts:
|
||||
ssh_opts += ' -o %s' % ikey
|
||||
|
||||
# we should always have finalized string here.
|
||||
os.environ["GIT_SSH_OPTS"] = ssh_opts
|
||||
|
||||
# older than 2.3 does not know how to use git_ssh_opts,
|
||||
# so we force it into ssh command var
|
||||
# older than 2.3 does not know how to use git_ssh_command,
|
||||
# so we force it into get_ssh var
|
||||
# https://github.com/gitster/git/commit/09d60d785c68c8fa65094ecbe46fbc2a38d0fc1f
|
||||
if git_version < LooseVersion('2.3.0'):
|
||||
# for use in wrapper
|
||||
os.environ["GIT_SSH_OPTS"] = ssh_opts
|
||||
|
||||
# these versions don't support GIT_SSH_OPTS so have to write wrapper
|
||||
wrapper = write_ssh_wrapper(module)
|
||||
|
||||
# force use of git_ssh_opts via wrapper
|
||||
os.environ["GIT_SSH"] = wrapper
|
||||
|
||||
# same as above but older git uses git_ssh_command
|
||||
os.environ["GIT_SSH_COMMAND"] = wrapper
|
||||
# force use of git_ssh_opts via wrapper, git_ssh cannot not handle arguments
|
||||
os.environ['GIT_SSH'] = wrapper
|
||||
else:
|
||||
# we construct full finalized command string here
|
||||
full_cmd = os.environ.get('GIT_SSH', os.environ.get('GIT_SSH_COMMAND', 'ssh'))
|
||||
if ssh_opts:
|
||||
full_cmd += ' ' + ssh_opts
|
||||
# git_ssh_command can handle arguments to ssh
|
||||
os.environ["GIT_SSH_COMMAND"] = full_cmd
|
||||
|
||||
|
||||
def get_version(module, git_path, dest, ref="HEAD"):
|
||||
|
||||
@ -159,12 +159,11 @@ EXAMPLES = '''
|
||||
- bottle>0.10,<0.20,!=0.11
|
||||
|
||||
- name: Install python package using a proxy
|
||||
# Pip doesn't use the standard environment variables, please use the CAPITALIZED ones below
|
||||
ansible.builtin.pip:
|
||||
name: six
|
||||
environment:
|
||||
HTTP_PROXY: '127.0.0.1:8080'
|
||||
HTTPS_PROXY: '127.0.0.1:8080'
|
||||
http_proxy: 'http://127.0.0.1:8080'
|
||||
https_proxy: 'https://127.0.0.1:8080'
|
||||
|
||||
# You do not have to supply '-e' option in extra_args
|
||||
- name: Install MyApp using one of the remote protocols (bzr+,hg+,git+,svn+)
|
||||
|
||||
@ -114,13 +114,13 @@ EXAMPLES = """
|
||||
# ansible all -m ansible.builtin.setup -a 'filter=facter_*'
|
||||
|
||||
# Collect only facts returned by facter.
|
||||
# ansible all -m ansible.builtin.setup -a 'gather_subset=!all,!any,facter'
|
||||
# ansible all -m ansible.builtin.setup -a 'gather_subset=!all,facter'
|
||||
|
||||
- name: Collect only facts returned by facter
|
||||
ansible.builtin.setup:
|
||||
gather_subset:
|
||||
- '!all'
|
||||
- '!any'
|
||||
- '!<any valid subset>'
|
||||
- facter
|
||||
|
||||
- name: Collect only selected facts
|
||||
@ -137,7 +137,7 @@ EXAMPLES = """
|
||||
# ansible all -m ansible.builtin.setup -a 'gather_subset=network,virtual'
|
||||
|
||||
# Collect only network and virtual (excludes default minimum facts)
|
||||
# ansible all -m ansible.builtin.setup -a 'gather_subset=!all,!any,network,virtual'
|
||||
# ansible all -m ansible.builtin.setup -a 'gather_subset=!all,network,virtual'
|
||||
|
||||
# Do not call puppet facter or ohai even if present.
|
||||
# ansible all -m ansible.builtin.setup -a 'gather_subset=!facter,!ohai'
|
||||
|
||||
@ -26,6 +26,8 @@ options:
|
||||
version_added: '2.4'
|
||||
notes:
|
||||
- For Windows you can use M(ansible.windows.win_template) which uses '\\r\\n' as C(newline_sequence) by default.
|
||||
- The C(jinja2_native) setting has no effect. Native types are never used in the C(template) module which is by design used for generating text files.
|
||||
For working with templates and utilizing Jinja2 native types see the C(jinja2_native) parameter of the C(template lookup).
|
||||
seealso:
|
||||
- module: ansible.builtin.copy
|
||||
- module: ansible.windows.win_copy
|
||||
|
||||
@ -8,6 +8,7 @@ __metaclass__ = type
|
||||
import fcntl
|
||||
import os
|
||||
import shlex
|
||||
import typing as t
|
||||
|
||||
from abc import abstractmethod
|
||||
from functools import wraps
|
||||
@ -48,7 +49,7 @@ class ConnectionBase(AnsiblePlugin):
|
||||
# When running over this connection type, prefer modules written in a certain language
|
||||
# as discovered by the specified file extension. An empty string as the
|
||||
# language means any language.
|
||||
module_implementation_preferences = ('',) # type: tuple[str, ...]
|
||||
module_implementation_preferences = ('',) # type: t.Iterable[str]
|
||||
allow_executable = True
|
||||
|
||||
# the following control whether or not the connection supports the
|
||||
|
||||
@ -320,7 +320,7 @@ class Connection(ConnectionBase):
|
||||
display.vvvvv("creating Kerberos CC at %s" % self._kerb_ccache.name)
|
||||
krb5ccname = "FILE:%s" % self._kerb_ccache.name
|
||||
os.environ["KRB5CCNAME"] = krb5ccname
|
||||
krb5env = dict(KRB5CCNAME=krb5ccname)
|
||||
krb5env = dict(PATH=os.environ["PATH"], KRB5CCNAME=krb5ccname)
|
||||
|
||||
# Add any explicit environment vars into the krb5env block
|
||||
kinit_env_vars = self.get_option('kinit_env_vars')
|
||||
|
||||
@ -19,6 +19,6 @@
|
||||
from __future__ import (absolute_import, division, print_function)
|
||||
__metaclass__ = type
|
||||
|
||||
__version__ = '2.13.0.dev0'
|
||||
__version__ = '2.13.0b1'
|
||||
__author__ = 'Ansible, Inc.'
|
||||
__codename__ = "Nobody's Fault but Mine"
|
||||
|
||||
@ -674,6 +674,7 @@ class Templar:
|
||||
extensions=self._get_extensions(),
|
||||
loader=FileSystemLoader(loader.get_basedir() if loader else '.'),
|
||||
)
|
||||
self.environment.template_class.environment_class = environment_class
|
||||
|
||||
# jinja2 global is inconsistent across versions, this normalizes them
|
||||
self.environment.globals['dict'] = dict
|
||||
|
||||
@ -353,8 +353,7 @@ class VariableManager:
|
||||
try:
|
||||
play_search_stack = play.get_search_path()
|
||||
found_file = real_file = self._loader.path_dwim_relative_stack(play_search_stack, 'vars', vars_file)
|
||||
decrypted_file = self._loader.get_real_file(found_file)
|
||||
data = preprocess_vars(self._loader.load_from_file(decrypted_file, unsafe=True))
|
||||
data = preprocess_vars(self._loader.load_from_file(found_file, unsafe=True, cache=False))
|
||||
if data is not None:
|
||||
for item in data:
|
||||
all_vars = _combine_and_track(all_vars, item, "play vars_files from '%s'" % vars_file)
|
||||
|
||||
2
test/integration/targets/pyyaml/aliases
Normal file
2
test/integration/targets/pyyaml/aliases
Normal file
@ -0,0 +1,2 @@
|
||||
shippable/posix/group5
|
||||
context/controller
|
||||
11
test/integration/targets/pyyaml/runme.sh
Executable file
11
test/integration/targets/pyyaml/runme.sh
Executable file
@ -0,0 +1,11 @@
|
||||
#!/usr/bin/env bash
|
||||
|
||||
set -eu
|
||||
source virtualenv.sh
|
||||
set +x
|
||||
|
||||
# deps are already installed, using --no-deps to avoid re-installing them
|
||||
# Install PyYAML without libyaml to validate ansible can run
|
||||
PYYAML_FORCE_LIBYAML=0 pip install --no-binary PyYAML --ignore-installed --no-cache-dir --no-deps PyYAML
|
||||
|
||||
ansible --version | tee /dev/stderr | grep 'libyaml = False'
|
||||
@ -1,6 +1,6 @@
|
||||
base image=quay.io/ansible/base-test-container:2.2.0 python=3.10,2.7,3.5,3.6,3.7,3.8,3.9 seccomp=unconfined
|
||||
default image=quay.io/ansible/default-test-container:5.8.0 python=3.10,2.7,3.5,3.6,3.7,3.8,3.9 seccomp=unconfined context=collection
|
||||
default image=quay.io/ansible/ansible-core-test-container:5.8.0 python=3.10,2.7,3.5,3.6,3.7,3.8,3.9 seccomp=unconfined context=ansible-core
|
||||
default image=quay.io/ansible/default-test-container:5.9.0 python=3.10,2.7,3.5,3.6,3.7,3.8,3.9 seccomp=unconfined context=collection
|
||||
default image=quay.io/ansible/ansible-core-test-container:5.9.0 python=3.10,2.7,3.5,3.6,3.7,3.8,3.9 seccomp=unconfined context=ansible-core
|
||||
alpine3 image=quay.io/ansible/alpine3-test-container:3.3.0 python=3.9
|
||||
centos7 image=quay.io/ansible/centos7-test-container:3.1.0 python=2.7 seccomp=unconfined
|
||||
fedora34 image=quay.io/ansible/fedora34-test-container:3.1.0 python=3.9 seccomp=unconfined
|
||||
|
||||
@ -221,7 +221,7 @@ class NetworkInventoryTargetFilter(TargetFilter[NetworkInventoryConfig]):
|
||||
"""Target filter for network inventory."""
|
||||
|
||||
|
||||
class OriginTargetFilter(TargetFilter[OriginConfig]):
|
||||
class OriginTargetFilter(PosixTargetFilter[OriginConfig]):
|
||||
"""Target filter for localhost."""
|
||||
|
||||
|
||||
|
||||
@ -172,7 +172,14 @@ def delegate_command(args, host_state, exclude, require): # type: (EnvironmentC
|
||||
|
||||
if networks is not None:
|
||||
for network in networks:
|
||||
con.disconnect_network(network)
|
||||
try:
|
||||
con.disconnect_network(network)
|
||||
except SubprocessError:
|
||||
display.warning(
|
||||
'Unable to disconnect network "%s" (this is normal under podman). '
|
||||
'Tests will not be isolated from the network. Network-related tests may '
|
||||
'misbehave.' % (network,)
|
||||
)
|
||||
else:
|
||||
display.warning('Network disconnection is not supported (this is normal under podman). '
|
||||
'Tests will not be isolated from the network. Network-related tests may misbehave.')
|
||||
|
||||
@ -419,7 +419,7 @@ class OriginConfig(ControllerHostConfig, PosixConfig):
|
||||
@property
|
||||
def have_root(self): # type: () -> bool
|
||||
"""True if root is available, otherwise False."""
|
||||
return os.getuid() != 0
|
||||
return os.getuid() == 0
|
||||
|
||||
|
||||
@dataclasses.dataclass
|
||||
|
||||
@ -24,6 +24,10 @@ def main():
|
||||
else:
|
||||
continue
|
||||
|
||||
# In some situations offset can be None. This can happen for syntax errors on Python 2.6
|
||||
# (__future__ import following after a regular import).
|
||||
offset = offset or 0
|
||||
|
||||
result = "%s:%d:%d: %s: %s" % (path, lineno, offset, extype.__name__, safe_message(message))
|
||||
|
||||
if sys.version_info <= (3,):
|
||||
|
||||
@ -5,4 +5,4 @@ sphinx == 4.2.0
|
||||
sphinx-notfound-page
|
||||
sphinx-ansible-theme
|
||||
straight.plugin
|
||||
antsibull
|
||||
antsibull-docs
|
||||
|
||||
@ -4,8 +4,8 @@ aiohttp==3.8.0
|
||||
aiosignal==1.2.0
|
||||
alabaster==0.7.12
|
||||
ansible-pygments==0.1.0
|
||||
antsibull==0.42.0
|
||||
antsibull-changelog==0.14.0
|
||||
antsibull-core==1.0.0
|
||||
antsibull-docs==1.0.0
|
||||
async-timeout==4.0.1
|
||||
asyncio-pool==0.5.2
|
||||
attrs==21.2.0
|
||||
|
||||
@ -18,6 +18,7 @@ import yaml
|
||||
|
||||
from io import BytesIO, StringIO
|
||||
from mock import MagicMock, patch
|
||||
from unittest import mock
|
||||
|
||||
import ansible.module_utils.six.moves.urllib.error as urllib_error
|
||||
|
||||
@ -27,6 +28,7 @@ from ansible.errors import AnsibleError
|
||||
from ansible.galaxy import collection, api, dependency_resolution
|
||||
from ansible.galaxy.dependency_resolution.dataclasses import Candidate, Requirement
|
||||
from ansible.module_utils._text import to_bytes, to_native, to_text
|
||||
from ansible.module_utils.common.process import get_bin_path
|
||||
from ansible.utils import context_objects as co
|
||||
from ansible.utils.display import Display
|
||||
|
||||
@ -172,6 +174,22 @@ def galaxy_server():
|
||||
return galaxy_api
|
||||
|
||||
|
||||
def test_concrete_artifact_manager_scm_no_executable(monkeypatch):
|
||||
url = 'https://github.com/org/repo'
|
||||
version = 'commitish'
|
||||
mock_subprocess_check_call = MagicMock()
|
||||
monkeypatch.setattr(collection.concrete_artifact_manager.subprocess, 'check_call', mock_subprocess_check_call)
|
||||
mock_mkdtemp = MagicMock(return_value='')
|
||||
monkeypatch.setattr(collection.concrete_artifact_manager, 'mkdtemp', mock_mkdtemp)
|
||||
|
||||
error = re.escape(
|
||||
"Could not find git executable to extract the collection from the Git repository `https://github.com/org/repo`"
|
||||
)
|
||||
with mock.patch.dict(os.environ, {"PATH": ""}):
|
||||
with pytest.raises(AnsibleError, match=error):
|
||||
collection.concrete_artifact_manager._extract_collection_from_git(url, version, b'path')
|
||||
|
||||
|
||||
@pytest.mark.parametrize(
|
||||
'url,version,trailing_slash',
|
||||
[
|
||||
@ -194,10 +212,12 @@ def test_concrete_artifact_manager_scm_cmd(url, version, trailing_slash, monkeyp
|
||||
repo = 'https://github.com/org/repo'
|
||||
if trailing_slash:
|
||||
repo += '/'
|
||||
clone_cmd = ('git', 'clone', repo, '')
|
||||
|
||||
git_executable = get_bin_path('git')
|
||||
clone_cmd = (git_executable, 'clone', repo, '')
|
||||
|
||||
assert mock_subprocess_check_call.call_args_list[0].args[0] == clone_cmd
|
||||
assert mock_subprocess_check_call.call_args_list[1].args[0] == ('git', 'checkout', 'commitish')
|
||||
assert mock_subprocess_check_call.call_args_list[1].args[0] == (git_executable, 'checkout', 'commitish')
|
||||
|
||||
|
||||
@pytest.mark.parametrize(
|
||||
@ -223,10 +243,11 @@ def test_concrete_artifact_manager_scm_cmd_shallow(url, version, trailing_slash,
|
||||
repo = 'https://github.com/org/repo'
|
||||
if trailing_slash:
|
||||
repo += '/'
|
||||
shallow_clone_cmd = ('git', 'clone', '--depth=1', repo, '')
|
||||
git_executable = get_bin_path('git')
|
||||
shallow_clone_cmd = (git_executable, 'clone', '--depth=1', repo, '')
|
||||
|
||||
assert mock_subprocess_check_call.call_args_list[0].args[0] == shallow_clone_cmd
|
||||
assert mock_subprocess_check_call.call_args_list[1].args[0] == ('git', 'checkout', 'HEAD')
|
||||
assert mock_subprocess_check_call.call_args_list[1].args[0] == (git_executable, 'checkout', 'HEAD')
|
||||
|
||||
|
||||
def test_build_requirement_from_path(collection_artifact):
|
||||
|
||||
@ -709,3 +709,16 @@ def test_no_log_none(stdin, capfd):
|
||||
# makes it into am.no_log_values. Instead we can check for the warning
|
||||
# emitted by am._log_invocation.
|
||||
assert len(get_warning_messages()) > 0
|
||||
|
||||
|
||||
@pytest.mark.parametrize("stdin", [{"pass": "testing"}], indirect=["stdin"])
|
||||
def test_no_log_alias(stdin, capfd):
|
||||
"""Given module parameters that use an alias for a parameter that matches
|
||||
PASSWORD_MATCH and has no_log=True set, a warning should not be issued.
|
||||
"""
|
||||
arg_spec = {
|
||||
"other_pass": {"no_log": True, "aliases": ["pass"]},
|
||||
}
|
||||
am = basic.AnsibleModule(arg_spec)
|
||||
|
||||
assert len(get_warning_messages()) == 0
|
||||
|
||||
@ -95,6 +95,11 @@ def test_aliases(arg_spec, parameters, expected, deprecation, warning):
|
||||
assert isinstance(result, ValidationResult)
|
||||
assert result.validated_parameters == expected
|
||||
assert result.error_messages == []
|
||||
assert result._aliases == {
|
||||
alias: param
|
||||
for param, value in arg_spec.items()
|
||||
for alias in value.get("aliases", [])
|
||||
}
|
||||
|
||||
if deprecation:
|
||||
assert deprecation == result._deprecations[0]
|
||||
|
||||
@ -6,6 +6,8 @@
|
||||
from __future__ import (absolute_import, division, print_function)
|
||||
__metaclass__ = type
|
||||
|
||||
import os
|
||||
|
||||
import pytest
|
||||
|
||||
from io import StringIO
|
||||
@ -255,8 +257,9 @@ class TestWinRMKerbAuth(object):
|
||||
assert len(mock_calls) == 1
|
||||
assert mock_calls[0][1] == expected
|
||||
actual_env = mock_calls[0][2]['env']
|
||||
assert list(actual_env.keys()) == ['KRB5CCNAME']
|
||||
assert sorted(list(actual_env.keys())) == ['KRB5CCNAME', 'PATH']
|
||||
assert actual_env['KRB5CCNAME'].startswith("FILE:/")
|
||||
assert actual_env['PATH'] == os.environ['PATH']
|
||||
|
||||
@pytest.mark.parametrize('options, expected', [
|
||||
[{"_extras": {}},
|
||||
@ -287,8 +290,9 @@ class TestWinRMKerbAuth(object):
|
||||
mock_calls = mock_pexpect.mock_calls
|
||||
assert mock_calls[0][1] == expected
|
||||
actual_env = mock_calls[0][2]['env']
|
||||
assert list(actual_env.keys()) == ['KRB5CCNAME']
|
||||
assert sorted(list(actual_env.keys())) == ['KRB5CCNAME', 'PATH']
|
||||
assert actual_env['KRB5CCNAME'].startswith("FILE:/")
|
||||
assert actual_env['PATH'] == os.environ['PATH']
|
||||
assert mock_calls[0][2]['echo'] is False
|
||||
assert mock_calls[1][0] == "().expect"
|
||||
assert mock_calls[1][1] == (".*:",)
|
||||
|
||||
Reference in New Issue
Block a user