As a user
Big changes don’t seem to be properly tested
Latest developments
This was discussed at CfgMgmtCamp 2026.
I think the message arrived (and already had arrived in the past) that some of the problems around ansible-core 2.19 were unnecessary and have been prevented. This was apparently discussed internally and some teams are now more aware of the problems.
ansible.netcommon now also tests against ansible-core’s devel branch.
Original text
This aims at Data Tagging - which I think is a really awesome feature! One of the main first uses of Data Tagging is the inversion of Ansible’s trust model: a string now will be templated if it is explicitly tagged as safe. (Before, strings were not templated if they were explicitly tagged as unsafe.)
Another uses are tagging a data’s origin, which allows to show better error messages that often point to where something comes from that causes a problem. And then it is now possible to properly deprecate module return values: if a user actually uses them, they see a deprecation message.
More uses are planned, like improving handling of sensitive data.
This is a huge change, and unsurprisingly made a quite a few long-term users unhappy since it broke their existing roles and playbooks, and some of their patterns of how to write these.
Some of these problems are unavoidable, and some could have been softened by more advance deprecations. (Some problems were already fixed, and some others were promised or at least suggested that they might get addressed, but changes didn’t materialize so far.)
There were also quite a few bugs in the implementation, some that were found before the ansible-core 2.19 GA release, but some only afterwards. Obviously such a huge change always comes with bugs that no matter how much you test you will never find until a user discovers them. But there were also quite a few things that could have been prevented.
The most obvious ones were code in ansible.netcommon and cloud.common that simply did not work with ansible-core 2.19, and there was no good way to fix these collections without changes in ansible-core itself. (cloud.common is probably long-term broken, and upon discovering it we had to scramble to get rid of it from Ansible 12 since it was a dependency of one of the vmware collections.) Now this shouldn’t be a problem, since ansible-core, ansible.netcommon, and cloud.common are all maintained by Red Hat’s Ansible division, and such big changes will surely be tested internally to avoid such breakage, especially before a release.
Well.
This didn’t happen, and ansible-core 2.19 GA got released without these problems fixed. In the case of ansible.netcommon, the problems were reported (May 25th) almost two months before ansible-core 2.19’s GA (July 21st), and affected many network collections.
(Another compatibility issue with ansible.netcommon which apparently affects many network modules was [only fixed in January 2026](Ansible Collections · GitHub ansible.netcommon/pull/743). I guess this is a feature that wasn’t tested in CI anywhere. It’s now also deprecated…)
So it seems that even in Red Hat’s Ansible division, huge features aren’t tested by many outside the team introducing them. I don’t know how the internals of Red Hat work, but from the outside, this is very embarrassing from the outside.
(I can’t say much about how this can be improved since I have no idea how things work inside of Red Hat. But I think it’s fair to say that things have to be improved.)
(One interesting fact that basically happened only on January 23rd, 2026: the next ansible-core 2.18 release, 2.18.13, will have a new feature: it will finally show deprecation messages in some situations which are now an error in ansible-core 2.19. The funny thing is that this has been mentioned as a possibility already quite some time back, and ansible-core 2.18 is in “security fixes only” mode already since November 2025. While I think it is great that this deprecation is added to ansible-core 2.18 to help migration to 2.19, it did happen more than half a year too late. But well, better late than never… This check also got backported to ansible-core 2.16 and will appear in ansible-core 2.16.16. In fact, the 2.18 backport is a forward-port of the 2.16 backport… This also means that we now have a new feature in ansible-core 2.16 and 2.18 that is not present in ansible-core 2.17.)