Ansible-base 2.11 Porting Guide¶
This section discusses the behavioral changes between Ansible-base 2.10 and Ansible-base 2.11.
It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible-base.
We suggest you read this page along with the Ansible-base Changelog for 2.11 to understand what updates you may need to make.
Ansible-base is mainly of interest for developers and users who only want to use a small, controlled subset of the available collections. Regular users should install ansible.
The complete list of porting guides can be found at porting guides.
Contents
Playbook¶
- The
jinja2_native
setting now does not affect the template module which implicitly returns strings. For the template lookup there is a new argumentjinja2_native
(off by default) to control that functionality. The rest of the Jinja2 expressions still operate based on thejinja2_native
setting.
Command Line¶
- The
ansible-galaxy login
command has been removed, as the underlying API it used for GitHub auth is being shut down. Publishing roles or collections to Galaxy viaansible-galaxy
now requires that a Galaxy API token be passed to the CLI via a token file (default location~/.ansible/galaxy_token
) or (insecurely) via the--token
argument toansible-galaxy
.
Deprecated¶
No notable changes
Modules¶
- The
apt_key
module has explicitly definedfile
as mutually exclusive withdata
,keyserver
andurl
. They cannot be used together anymore. - The
meta
module now supports tags for user-defined tasks. Set the task’s tags to ‘always’ to maintain the previous behavior. Internalmeta
tasks continue to always run.
Deprecation notices¶
No notable changes
Noteworthy module changes¶
- facts - On NetBSD,
ansible_virtualization_type
now tries to report a more accurate result thanxen
when virtualized and not running on Xen. - facts - Virtualization facts now include
virtualization_tech_guest
andvirtualization_tech_host
keys. These are lists of virtualization technologies that a guest is a part of, or that a host provides, respectively. As an example, a host may be set up to provide both KVM and VirtualBox, and these will be included invirtualization_tech_host
, and a podman container running on a VM powered by KVM will have avirtualization_tech_guest
of["kvm", "podman", "container"]
. - The parameter
filter
type is changed fromstring
tolist
in the setup module in order to use more than one filter. Previous behaviour (using astring
) still remains and works as a single filter.
Plugins¶
- inventory plugins -
CachePluginAdjudicator.flush()
now calls the underlying cache plugin’sflush()
instead of only deleting keys that it knows about. Inventory plugins should usedelete()
to remove any specific keys. As a user, this means that when an inventory plugin calls itsclear_cache()
method, facts could also be flushed from the cache. To work around this, users can configure inventory plugins to use a cache backend that is independent of the facts cache. - callback plugins -
meta
task execution is now sent tov2_playbook_on_task_start
like any other task. By default, only explicit meta tasks are sent there. Callback plugins can opt-in to receiving internal, implicitly created tasks to act on those as well, as noted in the plugin development documentation.
Porting custom scripts¶
No notable changes