Support Ansible 12 (ansible-core 2.19)

[stefanor]

Debian is looking at Ansible 12 support early, as we're entering the early stages of freeze now for Debian 13 (Trixie) and expect Ansible 12 to release well before we freeze solid.

[carnil]

FWIW, the report in Ansible is at: https://github.com/ansible/ansible/issues/85017

[upekkha]

Ansible 12 is deprecating custom strategy plugins like mitogen: ansible/ansible/issues/84725

Use of strategy plugins not included in ansible.builtin are deprecated and do not carry any backwards compatibility guarantees. No alternative for third party strategy plugins is currently planned. This feature will be removed in a future release.

[moreati]

Notes to self

• Debian 13 (Trixie)
  • 15 Apr 2025 soft freeze, 15 May hard freeze
  • Ships Python 3.13
• Ansible 12 (core 2.19)
  • 16 Apr 2025 core feature freeze, ~~26 May~~ 30 June core RC1, 21 July 2.19.0
  • Controller: Python 3.11 - 3.13 (unchanged from Ansible 11 (core 2.18))
  • Targets: Python 3.8 - 3.13 (also unchanged)

Refs

1. https://wiki.debian.org/DebianTrixie
2. https://distrowatch.com/table.php?distribution=debian
3. https://docs.ansible.com/ansible/devel/roadmap/COLLECTIONS_12.html
4. https://docs.ansible.com/ansible/devel/reference_appendices/release_and_maintenance.html#ansible-core-support-matrix
5. https://forum.ansible.com/t/core-2-19-beta-extended-thru-june-30/43035

[moreati]

ansible.parsing.utils.jsonify was removed in https://github.com/ansible/ansible/pull/84621 (Templating overhaul, Data Tagging), some fallout reported/discussed in https://github.com/ansible/ansible/issues/85017, restored with deprecation warning in https://github.com/ansible/ansible/pull/85032.

[moreati]

Prior to removal/restorationansible.parsing.utils.jsonify.jsonify() changed very little. Differences to json.dumps()

1. jsonify(None) -> u'{}' vs dumps(None) -> u'null'
2. jsonify(..., format: bool) vs dumps(..., indent: int|None, ...)
3. jsonify() always applies sort_keys=True.
4. jsonify() prefers ensure_ascii=False, falling back to ensure_ascii=True on UnicodeDecodeError. I'm unsure what would trigger that exception only in the former case.

Refs

1. https://github.com/ansible/ansible/blame/a0495fc31497798a7a833ba7406a9729e1528dd8/lib/ansible/parsing/utils/jsonify.py
2. https://docs.python.org/3/library/json.html#basic-usage

[moreati]

Porting guide items that caught my eye

Changes to templating in this release detects non-boolean conditionals during expression evaluation and reports an error by default. The error can be temporarily reduced to a warning with the ALLOW_BROKEN_CONDITIONALS config setting.

Playbook conditionals (e.g. when: ...) must evaluate to a boolean type. Relying on implicit Truthy semantics a lá Jinja or Python is now considered an error.

Embedding templates within other templates or expressions could previously result in untrusted templates being executed. The overhauled templating engine in this release no longer supports this insecure behavior.

This means {{ ... }} inside an assert:, or when: is an error, e.g.

- assert:
    that: 1 + {{ value }} == 2

Changelog doesn't mention https://docs.ansible.com/ansible/devel/reference_appendices/config.html#allow-embedded-templates

By default, untrusted templates are silently ignored. Troubleshooting trust issues with templates can be aided by enabling warnings or errors for untrusted templates. The environment variable _ANSIBLE_TEMPLAR_UNTRUSTED_TEMPLATE_BEHAVIOR can be used to control this behavior.

No mention of _ANSIBLE_TEMPLAR_UNTRUSTED_TEMPLATE_BEHAVIOR in config reference.

Timeout waiting on privilege escalation (become) is now an unreachable error instead of a task error. Existing playbooks should be changed to replace ignore_errors with ignore_unreachable on tasks where timeout on become should be ignored.

May have bearing on https://github.com/mitogen-hq/mitogen/blob/master/docs/ansible_detailed.rst?plain=1#L226-L244

Previously, ansible-core implicitly trusted all string values to be rendered as Jinja templates, but applied an “unsafe” wrapper object [...] This required any code that operated on strings to correctly propagate the wrapper object, which resulted in numerous CVE-worthy RCE (remote code execution) vulnerabilities. This release inverts the previous trust model. Only strings marked as loaded from a trusted source are eligible to be rendered as templates. Untrusted values can (as before) be referenced by templates, but the template expression itself must always be trusted. While this change still requires consideration for propagation of trust markers when manipulating strings, failure to do so now results in a loss of templating ability instead of a potentially high-severity security issue.

Jinja’s native templating mode is now used exclusively. The configuration option for setting the templating mode is deprecated and no longer has any effect.

Handling of errors, warnings and deprecations throughout much of the ansible-core codebase has now been standardized. Tracebacks can be optionally collected and displayed for all exceptions, as well as at the call site of errors, warnings, or deprecations (even in module code) using the ANSIBLE_DISPLAY_TRACEBACK environment variable.

The ssh connection plugin now supports using SSH_ASKPASS to supply passwords for authentication as an alternative to the sshpass program. The default is to use SSH_ASKPASS instead of sshpass. This is controlled by the password_mechanism configuration for the ssh connection plugin

Coercing unrecognized input values in the bool filter is deprecated

Most values (other than True, False, 1, 0, '1', '0', 'yes', 'no') now emit a deprecation warning, e.g. "" | bool, None | bool

• internals - The AnsibleLoader and AnsibleDumper classes for working with YAML are now factory functions and cannot be extended.
• internals - The ansible.utils.native_jinja Python module has been removed.
• Task Execution / Forks - Forks no longer inherit stdio from the parent ansible-playbook process. stdout, stderr, and stdin within a worker are detached from the terminal, and non-functional. All needs to access stdio from a fork for controller side plugins requires use of Display. -- https://github.com/ansible/ansible/pull/82770
• modules - Modules returning non-UTF8 strings now result in an error. The MODULE_STRICT_UTF8_RESPONSE setting can be used to disable this check.
• removed deprecated pycompat24 and compat.importlib.
• yaml callback plugin - deprecate plugin in favor of result_format=yaml in plugin ansible.bulitin.default

Refs

1. https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_12.html

[stefanor]

We have also been receiving reports of a regression in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1103652#34 that I haven't been able to reproduce.

[rfc1036]

I confirm that https://github.com/upekkha/mitogen/commit/98827c5ce7ed2fe35eb247374106777421546702 fixes the Debian bug that I reported.

[zerwes]

for the record: debian trixie will come with ansible==12.0.0~a2 ansible-core==2.19.0~beta2 ref: https://packages.debian.org/trixie/ansible

[moreati]

https://forum.ansible.com/t/making-a-collection-compatible-with-core-2-19-and-templating-changes/41717

[moreati]

Thanks @stefanor, @upekkha et al. Pre-release v0.3.25a is out https://github.com/mitogen-hq/mitogen/releases/tag/v0.3.25a1

[zerwes]

we currently work on porting our ansible roles step by step to support ansible 12/ansible-core 2.19 so your pre-release is much appreciated, thank you for your effort!

First thing I noticed, while starting de tests wit the new mitogen release:

[DEPRECATION WARNING]: Use of strategy plugins not included in ansible.builtin are deprecated and do not carry any backwards compatibility guarantees. No alternative for third party strategy plugins is currently planned. This feature will be removed from ansible-core in a future release.

so it looks like after ansible-core 2.19 is before ansible-core 2.23 :(

current setup:

ansible==12.0.0a5
ansible-core==2.19.0b5

with mitogen v0.3.25a1

[moreati]

Mitogen should still work with Ansible 12 (ansible-core 2.19). If your playbook failed to run then please open an issue.

The deprecation warning you've quoted is a warning, not an error. The Ansible project is giving plenty of advance notice (> 1 year) that a feature will be removed in a future release, but it's still present now. I've created #1272 to document this better in Mitogen's docs.

In the longer term, Mitogen will need to re-evaluate how it integrates with Ansible.

[zerwes]

Sorry @moreati - yes, it is just a warning and until ansible 2.23 there is much time to consider a solution. The v0.3.25a1 version runs without problems until now, and I'll like to thank all persons involved for the release, as we needed to deactivated mitogen first for the ansible 12 porting ... and suddenly we realized the speed improvement mitogen bring - sometimes it is quite wholesome to have a break from good things you get used to, in order to learn to value it again 👍

[upekkha]

I also get

[DEPRECATION WARNING]: 'ansible.parsing.utils.jsonify' is deprecated. This feature will be removed from ansible-core version 2.23. Call `json.dumps` directly instead.

Adapting two lines in ansible_mitogen/mixins.py to use json.dumps instead removes the warning for me. Is there any reason to stick with ansible.parsing.utils.jsonify?

[stefanor]

use json.dumps instead

It's not quite that simple. See: https://github.com/mitogen-hq/mitogen/pull/1264#issuecomment-2881190602

[moreati]

Oops, I didn't realise Ansible kept the jsonify() deprecation warning after the revert. Raised #1274

[moreati]

Ansible 12.0a6 (ansible-core 2.19b6) includes changes to AnsiballZ and module reloading https://github.com/ansible/ansible/blob/v2.19.0b6/changelogs/CHANGELOG-v2.19.rst#v2-19-0b6. Historically those have been breakage points for Mitogen, so worth testing.

[zerwes]

Ansible 12.0a6 (ansible-core 2.19b6) includes changes to AnsiballZ and module reloading https://github.com/ansible/ansible/blob/v2.19.0b6/changelogs/CHANGELOG-v2.19.rst#v2-19-0b6. Historically those have been breakage points for Mitogen, so worth testing.

no rest on the ansible 12 battle field ... I have the impression the ansible guys wanted to give the world some thing like the py2to3 party in ansible terms ... with lot of broken porcelain and sweat and tears ...

I have updated yesterday our ansible12 dev branch to ansible==12.0.0a6 ansible-core==2.19.0b6 and at least our tests in CI/CD ran without issues. Yesterday I had other construction sites where I worked on, but latest on Monday I will do some real life tests (at least the part known to work with ansible12 until now).

[moreati]

Mitogen 0.3.25a2 removes the use of jsonify() https://github.com/mitogen-hq/mitogen/releases/tag/v0.3.25a2

[moreati]

https://pypi.org/project/ansible-core/2.19.0rc1/ released yesterday, fixes https://github.com/ansible/ansible/issues/85359 relevant to #1275

[moreati]

Current pre-releases

• Ansible 12.0.0a9, ansible-core 2.19.0rc2. Both released 2025-07-09.
• Mitogen 0.3.25a3 released 2025-07-02.

Expected dates

• 2025-07-21 ansible-core 2.19.0
• 2025-07-22 Ansible 12.0.0 beta1
• 2025-07-29 Ansible 12.0.0 rc1
• 2025-08-05 Ansible 12.0.0 (contingency 2025-08-12)
• 2025-08-09 Debian 13.0 (Trixie). Contains Ansible 12.0.0a6, ansible-core 2.19.0b6, Mitogen 0.3.25a1

Refs

• https://docs.ansible.com/ansible/devel/roadmap/COLLECTIONS_12.html
• https://lists.debian.org/debian-devel-announce/2025/07/msg00003.html

[moreati]

Released Mitogen 0.3.25b1, next release will likely be 0.3.25 to coincide with Ansible 12.0.0rc1.

[stefanor]

2025-08-09 Debian 13.0 (Trixie). Contains Ansible 12.0.0a6, ansible-core 2.19.0b6, Mitogen 0.3.25a1

Debian has a2. I don't think there's anything critical we're missing from a3 or b1. But there is time to cherry-pick any final patches if we need to.

[stefanor]

Oh, no, I lie. It hasn't migrated. I'll request that now.