All of my playbooks are failing after upgrading ansible-core from 2.18.7-1 to 2.19.0-1.
A simple playbook such as:
---
- name: Show info on cisco devices
hosts: <redacted>
connection: network_cli
gather_facts: false
vars:
ansible_network_os: ios
ansible_user: <redacted>
ansible_password: !vault | <redacted>
ansible_connect_timeout: 10
tasks:
- name: show me something
ios_command:
commands:
- show run | i hostname
register: output
- debug:
msg: "{{ output.stdout_lines }}"
Fails with the following error:
PLAY [Show info on cisco devices] ***********************************************************************************************************
TASK [show me something] ********************************************************************************************************************
[WARNING]: Deprecation warnings can be disabled by setting `deprecation_warnings=False` in ansible.cfg.
[DEPRECATION WARNING]: Passing `warnings` to `exit_json` or `fail_json` is deprecated. This feature will be removed from ansible-core version 2.23. Use `AnsibleModule.warn` instead.
[ERROR]: Task failed: ActionBase._parse_returned_data() missing 1 required positional argument: 'profile'
Origin: <redacted>.yaml:19:7
17
18 tasks:
19 - name: show me something
^ column 7
fatal: [<redacted>]: FAILED! => {"changed": false, "msg": "Task failed: ActionBase._parse_returned_data() missing 1 required positional argument: 'profile'"}
PLAY RECAP **********************************************************************************************************************************
<redacted> : ok=0 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0
Downgrading the ansible-core package back to 2.18.7-1 allows this playbook to run successfully. Anybody seeing similar issues or has any insight into this error? Hereās my environment:
ansible [core 2.19.0]
python version = 3.13.5 (main, Jun 21 2025, 09:35:00) [GCC 15.1.1 20250425] (/usr/bin/python)
jinja version = 3.1.6
pyyaml version = 6.0.2 (with libyaml v0.2.5)
Issue is reproduceable across multiple PCs running Arch Linux.
The recent enhancements in 2.19 broke the direct execution behavior of network content - specifically when ansible.netcommon patches _load_params during ActionModule calls, preventing argument loading from sys.argv.
Weāre actively working on a fix to restore the default behavior and improve _load_params() handling overall.
Temporary workaround while we get this sorted:
[all:vars]
ansible_network_import_modules=false
Note: This is just a quick unblock - it forcefully disables direct execution for network content. Not intended as a long-term solution, so youāll want to remove this once we ship the proper fix.
Thanks for your patience while we work through this!
Right now almost all of the network collections (arista.eos, junipernetwork.junos, cisco.ios, cisco.nxos) are broken with Ansible Core 2.19 which is part of Ansible Community 12. As of late July, 2025, Ansible Core 2.19 is currently released, and Ansible Community 12 will be released in a few days.
Most of the issues can be traced to netcommon, which most of them use for various functions. But at least a few (such as arista.avd) are broken in other ways as well.
The most common ways of installing Ansible for network admins are āpip3 install ansibleā or āpip3 install ansible-coreā, which will install the broken versions (pip3 install ansible installs 11 now, but will install 12 by default in a few days).
You can install Ansible 11/Core 2.18 by doing āpip3 install ansible~=11ā or āpip3 install ansible-core~=2.18ā to get the most recent minor release of 11/2.18, respectively.
I know thereās a fix in for netcommon and that should resolve some of the issues, perhaps all for your use case. But it might be a while before Ansible 12/Core 2.19 is suitable for the networking world.
Edit: Added error messages so network admins can find this post in searches:
Here are the error messages youād see with most networking modules using netcommond:
From the collections side, I can only say that community.routeros is working fine. (It doesnāt use functionality of ansible.netcommon that doesnāt work with ansible-core 2.19, apparently.)
The following network modules use netcommon, and there may be more.
CloudEngine
CNOS
Dell OS6/9/10
ENOS
Arista EOS
ERIC_ECCLI
EXOS
FRR
ICX
Cisco IOS
Cisco IOS XR
Cisco NXOS
Juniper Junos
NETVISOR
Extreme NOS
Extreme VOSS
RouterOS
SLX-OS
VyOS
Westermo WeOS 4 (never heard of that one)
Iāve only tested a few of them, and then only a module or two, but every one I tested was broken. I think thereās over a thousand modules between the collections, and Iām not going to test each one. I think itās better to assume theyāre all likely to be broken, even if a few modules do work. Since Ansible Community 11 and 2.18 are still active, itās safer to stay with them.
Iām a little frustrated that 2.19 was released even though there was a known problem as far back as May with netcommon, a collection that a lot of other modules rely on.
I agree that the current situation is really bad (and very frustrating), since a lot of collections apparently didnāt bother to ensure theyāre compatible with ansible-core 2.19.
I disagree that this should hold off ansible-core 2.19 though. Collections had half a year of time to get ready for this. There was a reminder to make sure the collections are compatible posted into every repository of every collection thatās part of Ansible community package at the end of April, so none of the maintainers can claim they never heard about ansible-core 2.19 coming up. The release date of ansible-core 2.19 has been moved by a month since that announcement, to give everyone more time. (TBH, I think that even if ansible-core 2.19 would have been delayed another month or two, the situation would still basically be the same as it is now.)
Yeah, I know a few maintainers have been caught off guard, but isnāt netcommon maintained by Red Hat? I would have thought this would have been a bit more coordinated.
For the record, we discussed making Ansible 11 a āLTSā (similar to Ansible 9) because of the changes introduced by Data Tagging in ansible-core 2.19. Long story short: We will provide minor and patch releases for 6 months longer, until Ansible 13 is released.
For people using the Ansible Community Package instead of ansible-core plus selected collections, this might make the decision easier if Ansible 11 is still an option. It will not be EOL once Ansible 12 is released, as originally planned!
@shadeland Welcome to the Ansible Forum, and thank you for sharing details about your experience.
We had an existing Forum thread about the issues with ansible.netcommon which powers the other collections you mentioned, so Iāve merged the two discussion threads.
It will not be EOL once Ansible 12 is released, as originally planned!
Ah, that was confusing. I though that Ansible community was supported for the previous two versions. If Ansible Community 11 is EOL, thatās a big deal for the network community.
Usually Ansible X is EOL once Ansible X+1 is out. This has been like this forever. The only exception has been Ansible 9 (the last version to support Python 2.7 on the controller side), and now Ansible 11 (the last version without ansible-core 2.19). Also note that these versions are not LTS versions (in what folks clasically understand when they say āLTSā), but they simply get new releases with collections that still receive updates for the semantic version range thatās included in that Ansible release cycle. (Some collections might have new releases with new features; and some other collections might not even offer bugfixes and security fixes.)
Itās different for ansible-core: there the latest three stable branches are actively maintained (details), so until ansible-core 2.20 comes out later this year, ansible-core 2.17, 2.18, and 2.19 will receive updates (2.17 only security fixes; 2.18 security and major bugfixes; and 2.19 all kind of bugfixes).
Sharing some in-progress PRs that are targeted to address the problems at hand.
This does not require the workaround suggested previously. And fixes the direct execution behaviour of network modules.
The above-mentioned PRs are being tested. More updates regarding that will be shared.