On the Futility of Opening Ansible Issues

Remember the anonymous troll who chided me for writing a rant instead of opening a GitHub issue in the relevant Ansible repository? Well, I decided to be an open-source poster boy when I stumbled upon the next Ansible bug, and ended up feeling like a sweet summer child :(

I was troubleshooting a broken Cisco IOS template when I noticed that, even though the configuration commands were not accepted, Ansible cisco.ios.ios_config module reported no errors. I looked at the Ansible code, realized it wasn’t recognizing the specific error message, and opened an issue. After all, they’d just need to add another line to the list of known error messages.

What I got instead was a little better than “did you try configuring no router eigrp followed by router eigrp” response I got from an entry-level Cisco TAC operator1 when I reported an EIGRP bug pointing to the exact debugging message proving it was a bug. Instead of someone adding a single line to the Cisco IOS network_cli connection module, I got an explanation of the ansible_terminal_stderr_re parameter.

Nothing wrong with that as a workaround, but an error message like “IPv6 routing not enabled” is probably not so rare that it doesn’t deserve to be in the venerable list of known Cisco IOS error messages2, and (reading the issue history) it looks like one of the Ansible developers agreed with me.

Alas, nothing happened, and the issue was automatically closed months later. Maybe I’ll write a rant the next time 🤦‍♂️, that seems to produce better results 🤷‍♂️.


  1. I refuse to call that individual “an engineer”. ↩︎

  2. That list includes “BGP: Error initializing topology”. If someone knows how to get that one, please write a comment. ↩︎

Add comment
Sidebar