CfgMgmtCamp 2026 discussion (4/12): Speaking about deprecations (and warnings in general)

felixfontein
Sat, 07 Feb 2026 20:58:55 +0000
Project Discussions

As a user

Speaking about deprecations (and warnings in general)

Latest developments

This was discussed at CfgMgmtCamp 2026.

According to @nitzmahone, a lot of work for ansible-core 2.19 went into improving handling of errors and warnings. There are plans to assign IDs to specific warnings and deprecations to make it possible to control which ones to emit and which ones to ignore.

Apparently it is also possible to interpret warnings as errors since ansible-core 2.19,
and some errors as warnings. (I was not able to find a setting for that when doing a quick search, @nitzmahone can you help?)

So it looks like this will be addressed soon.

Original text

Generally playbooks should not result in warnings. This includes deprecation warnings, which announce that something that works now will stop working, or will behave differently in the future.

In programming, one often uses a zero-warning approach by turning on flags like “treat warnings as errors”. This makes compilers fail if they encounter any warning.

Sometimes it is not possible to fix a warning, or it is known that a warning is a false positive in a specific instance. For this it is usually possible to disable a specific warning for a specific section of code (or globally).

In Ansible land, you do not have such a granular way to disable/enable warnings. You can turn them off globally - but who actually wants to do that? Some of them appear when a situation arises nobody thought of, and it is important to not miss them.

(Or they tell you something will break or change, so you can fix it before suddenly your production system goes down because a playbook now behaves differently.)

It would be a lot better if there are ways to:

1. Disable (or enable) specific warnings globally (say, in ansible.cfg or with command-line options);

2. Disable (or enable) specific warnings locally (say, for tasks or blocks of tasks, or even task files, roles, plays, …).

Currently this is not possible mainly for one reason: there is no way to identify a (deprecation) warning. If warnings/deprecations would have identifiers (like ansible.builtin.inject_facts_as_vars_default_deprecation or community.docker.docker_container.runtime_warning.memory), one could ignore specific warnings while not hiding others - especially ones we aren’t aware of yet because they are new, or they were hidden in a large chunk of irrelevant warnings that we couldn’t specifically ignore before.

This is rather easy to fix:

allow warnings and deprecations to specify an identifier (and at some point in the future actually require them);

specify a rough syntax/convention for these identifiers, say a FQCN which includes the collection name where they come from, and potentially more information.

Blocking can then use this syntax together with wildcards. For example, you might want to ignore community.docker.docker_container.runtime_warning.*, but not any other warnings (or deprecations) emitted by community.docker.docker_container. Wildcards work best if there is some syntax/convention to follow.

I remember having seen feature requests for this already a looong time ago. (But couldn’t find them anymore…)

1 post - 1 participant

Read full topic