Has Ansible Team Abandoned Network Automation?
A month ago, I described how Ansible release 12 broke the network device configuration modules, the little engines (that could) that brought us from the dark days of copy-and-paste into the more-survivable land of configuration templates.
Three releases later (they just released 13.1), the same bug is still there (at least it was on a fresh Python virtual environment install I made on a Ubuntu 24.04 server on December 13th, 2025), making all device_config modules unusable (without changing your Ansible playbooks) for configuration templating. Even worse:
- The documentation of network modules (for example, arista.eos.eos_config) hasn’t changed and still claims one can use Jinja2 template file as the src parameter.
- I found no issues in either the Ansible core GitHub repo or the Arista collection repo complaining about this unwanted behavior.
What could that mean? Here are a few ideas from the end-user perspective:
- Nobody is brave enough to try pushing through the Ansible Windows Vista moment.
- Nobody cares enough to complain about yet another minor detail in a product that is
brokendifferent from previous releases in so many other ways. - Nobody uses configuration templates anymore; all the cool kids drink the Intent Kool-Aid.
- The oldtimers have working installations using old versions of the products; the newbies will try to replicate something they found on the Internet, decide they’re too stupid to make it work, and hopefully move to another solution.
- Worst case, people trying to enter the Network Automation land will decide it’s simpler to stay a CLI jockey than to deal with broken bloatware and useless documentation.
OK, and what could a devious mind conclude about the viability of Ansible for network automation projects:
- It’s evident nobody is testing even the most common network configuration modules, otherwise such a blatant bug couldn’t survive four releases (each of them having multiple pre-release versions)
- Even worse, the “lack of templating” behavior seems to be caused by something shared by many networking modules. Even that code hasn’t been tested.
Before you tell me that the paid Ansible product works (and I’m pretty sure it does), the attitude of releasing a product that’s useless for a particular well-publicized use case is no better than Juniper releasing a vJunos-something VM with a broken DHCP server on its management interface. One of the hoped-for side effects of releasing free stuff is to enhance uptake and grow the sales funnel; releasing broken stuff tends to have the opposite effect.
Making things worse, many Ansible network automation collections are abandonware. One has to look no further than the nokia.grpc collection1 that was last updated four years ago and still has open issues from 2020, including the Please Update the Collection one from 2023 saying “the SR OS collection hasn’t been updated in three years”
Draw your own conclusions :(
-
You could say I’m picking on Nokia. I might be, but someone decided to make netlab dependent on those collections, so I care about them more than some other random stuff. ↩︎
Maybe some people are waiting the whole time for someone filing an issue on GitHub. Open source is not free. Why not filing an issue yourself? Or even finding the issue in the code and submit a pull request? If not feasible why not looking for alternatives?
Awesome!!! I was waiting for this comment, and you didn't disappoint.
You might want to do a bit of research on GitHub before telling me that "open source is not free", or is that too much of a bother?
Also, I did open an issue with Ansible a long while ago, and even submitted a pull request. After going through the pains of pushing that PR through, I decided to invest my time in other open-source projects.
Finally, as we all know, Ansible is not just any open-source project, and I have a bit higher bar for a project mostly funded by an IT behemoth than for something single-handedly maintained by a random person in Nebraska since 2003.
Stop whining. You get what you pay.
Ansible engineer here. This blog was recently brought to my attention.
The Ansible team continues to maintain, develop and enhance Ansible Network Automation. The Ansible Project Release 12, which uses ansible-core 2.19, introduced significant changes to the templating engine due to the new data tagging feature. It is most likely that you are encountering this issue because of those changes.
References: https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759 https://www.reddit.com/r/ansible/comments/1k7n33q/preparing_your_playbooks_for_core219/
The latest product version, Ansible Automation Platform (AAP) 2.6, is based on ansible-core 2.16:
https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html-single/release_notes/index
This is the reason users who are running ansible-core versions pinned to the product release have not encountered this issue.
That said, it would have been very helpful for the Ansible Network team to triage and prioritize fixing these issues if they had been raised in the relevant GitHub repositories.
@Ganesh -- thanks a million for your answer.
> The latest product version, Ansible Automation Platform (AAP) 2.6, is based on ansible-core 2.16
That's a very useful hint. I might pin my Ansible installations to the ansible-core version used by AAP and change that once AAP moves forward.
> It would have been very helpful for the Ansible Network team to triage and prioritize fixing these issues if they had been raised in the relevant GitHub repositories
I completely agree, and if I were on the other side, I would be slightly worried that nobody did that, unless nobody is doing configuration templating any longer, in which case life's good.
> I completely agree, and if I were on the other side, I would be slightly worried that nobody did that, unless nobody is doing configuration templating any longer, in which case life's good.
Not only did nobody do that, it was first seen back in April and ignored for a few months: https://github.com/ansible-collections/ansible.netcommon/issues/698
I think there are two ways to use the various Ansible modules: Either use all the discreet modules (VLANS, OSPF, BGP, etc.) or use only command and config, the later to "Genesis Torpedo" replace the config built from a template. I think the later is more viable.
I also think the various vendors (Arista, Cisco) should take over these projects. Arista has AVD and they do quite a bit with theirs. Juniper just took their modules over IIRC.
With Arista, eos_configs works well though it doesn't have commit confirm, which would be really really great to have.
> I completely agree, and if I were on the other side, I would be slightly worried that nobody did that, unless nobody is doing configuration templating any longer, in which case life's good.
@Ivan Thanks for your response. To be honest, this did concern me as well, and I wondered why the Ansible Network community using the project version wasn’t engaging more with the broader Ansible community on the official forums.
The Ansible core team did reach out to the community through a forum post https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759 to gather feedback on the pre-release version of ansible-core 2.19.
If you have any thoughts or suggestions on how the Ansible community can improve communication and feedback loops, we’d really appreciate you sharing them.
@Tony Bourke
> Not only did nobody do that, it was first seen back in April and ignored for a few months: https://github.com/ansible-collections/ansible.netcommon/issues/698
Did you read the issue description? This issue was raised by an Ansible community team member on collection repository to raise awareness of the data tagging feature and its potential impact. In the comments, a contributor reported a specific problem, which was reviewed and addressed by the Ansible team.
I’m confident that if the issues discussed here had been raised in the appropriate GitHub repository, it would have been reviewed and addressed in a timely manner.
> Did you read the issue description?
I did. The issue was raise and 2.19 was released anyway, breaking just about every network Ansible collection. Juniper's, Cisco's, etc. (the issue was netcommon).
Several people brought this up, including myself, and the Ansible team delayed Ansible Community 12 until fixes were made to netcommon.
> The Ansible team delayed Ansible Community 12 until fixes were made to netcommon.
And still they missed another elephant in the room. Somewhat proves some of my points, I'd say 🤷♂️
Ganesh, I don't know what to make of your answer. It's half condescending, half tautological.
I hope you realize that we all can read, and we are aware of those changes for many months, as should be anyone using an upstream project.
Now, Ill be condescending. You were here, you learned about the issue, please report it back to your team, in the relevant git repositories.
While you do that, Ill enjoy my Makefiles, which are pretty much backward compatible for 50 years.
I've become more and more disheartened with the direction that the Ansible team is taking. It's become extremely apparent that the paid for Ansible Automation Platform is getting all of the love, ignoring those that have supported, developed for and evangelized Ansible for years as an option. Not even getting into the nightmare of what they did to AWX, but the features being more and more tied to AAP is a literal defination of enshittification.
At the time it made sense to use the GRPC collection, it was freshly created and allowed for both platforms to be configured in a similar way. Easier to maintain and switch between the two, was the thinking
Fast forward to 2025, and it turns out the SR OS team for whatever reason decided that this wasn't what they wanted to do. It is what it is.
It seems kind of arbitrary which toolkits vendors (like Nokia) like to support long-term. I have been recenty implementing Nokia SR OS automation with this:
https://github.com/nokia/pysros
I used to achieve similar results with Ansible + Jinja2 templating, but am now really considering ditching Ansible for good and going "pure Python". Yes, you have to do your own templating, variable imports, error handling etc., but in the end, it just might be worth it.
I've long since come to the conclusion that Ansible is far too fast-moving, and consequently too fragile an ecosystem, to rely very much on for large production networks. We still use it for specific targeted things, but increasingly find the vendor-specific modules to be useless for our needs (e.g. can't rename VLANs). I must learn a fundamentally new way to configure my routers and switches about once every 5-10 years. Whereas I must learn a substantially new way of doing <something> with Ansible at least once every six months, if I follow the current release.
I want to spend my time building useful networks, not RE-learning the tool that was supposed to save me time.
It would be enormously helpful if, like most other projects over the last 60 years, the MAJOR version number changed every time there was a breaking change, instead of semi-randomly on any given update.
In short, "move fast and break things" may work in the software world, but the entire philosophy is incompatible with production networks supporting 100k's of users.