Measure Twice, Cut Once: Ansible net_interface
As I was preparing the materials for Ansible 2.7 Update webinar sessions I wanted to dive deeper into declarative configuration modules, starting with “I wonder what’s going on behind the scenes”
No problem: configure EEM applet command logging on Cisco IOS and execute an ios_interface module (more about that in another blog post)
Next step: let’s see how multi-platform modules work. Ansible has net_interface module that’s supposed to be used to configure interfaces on many different platforms significantly simplifying Ansible playbooks.
Starting with the ios_interface sample playbook, I changed ios_interface call into net_interface, ran the playbook on IOS and NX-OS devices, and failed miserably:
What could possibly go wrong? Here’s a slide from my Ansible for Networking Engineers webinar explaining how platform-independent modules really work:
Got it? The net_interface module is just a thin layer of veneer using platform-specific something_interface modules (selected based on ansible_network_os variable) to do the real work.
Still doesn’t explain the failure, does it? Let’s check the parameters of ios_interface and nxos_interface (the modules implementing net_interface behind the scenes):
- ios_interface (and eos_interface) has a single parameter (state) specifying interface state. It can take four values: present, absent, up and down.
- nxos_interface has two parameters: state which accepts values present and absent, and admin_state which can be up or down.
You can probably see the problem by now: there’s absolutely no way you could bring an IOS and a NX-OS interface in UP state using the same set of parameters.
Old woodworkers had a saying that might be applicable to many software projects not just Ansible: “measure twice, cut once.” In this particular case it seems we’re in the “I cut it three times and it’s still too short” territory :(
As you wrote the right function call is selected based on the OS variable. There's not much to be gained by that.
What we need instead are common data models e.g. OpenConfig, IETF ^^
While the community tries to unify where possible, we all understand that when dealing predominately with a network CLI, data model unification can be challenging. Additionally, we have to be sensitive to the fact that sometimes environments want to be able to automate configurations using platform (or NOS) specific knobs. Without getting into a religious debate on the merits of such an approach, it is real and needs to be accounted for when building an application.
Finally to the comment about NAPALM. First let me say, I'm a fan of the NAPALM project and what its goals are. I believe there needs to be an understanding that what NAPALM is trying to accomplish and what Ansible is trying to accomplish are fundamentally different. With that said, the Ansible team has listened intently to the community and have been working to phase in full NAPALM support into Ansible. The Ansible team has gone halfway in getting the NAPALM connection plugin merged into Ansible (See: https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/connection/napalm.py) in 2.8. We have been working with the NAPALM community to defined specific activities to complete the last half of the enablement (ie NAPALM module support) but this has unfortunately stalled (See: https://github.com/napalm-automation/napalm-ansible/issues/148). We are still hopeful that at some point the remainder of the enablement will be prioritized by the NAPALM community.
Always happy to engage in constructive dialog about how we can make Ansible better.
Peter S
Ansible
@privateip
I've tested ansible sometime ago and had some problems and issues that were very difficult to troubleshoot without knowing ansible deeply.
I've had 2 serious issues on iosxr module. That's ok, it happens, so I have opened one pull request¹ and one issue² to fix it.
On my point of view here begins the real problem that can impact ansible if it is occuring with other users:
1- Error messages are too generic! I was having a problem with regexp - ansible couldn't identify a returning message from our equipment. What is the returned message to the user (me)? "Timeout!" How can I supposedly know that this "timeout" issue was in fact a problem in the regex expression!?
2- The 2 issues that I've opened are simples issues that could have been solved more quickly. It was 2 "simple" issues that, in my opinion, was easy to solve (or just accept the pull request!) but since version 2.7.8 wasn't solved... So, if I want to use ansible for our equipment, we have to edit python scripts to fix the 2 issues manually. That made it almost unusable in our environment.
So the question is: If this is happening with these 2 simple issues, what is happening with the other 4000+ opened issues? Can ansible team deal with that amount of problems? And: Where is Red Hat??? Can't they put more effort on this since it is becoming one of their major product?
1- https://github.com/ansible/ansible/pull/54817
2- https://github.com/ansible/ansible/issues/54878
--
[]'s
Lívio
Thank you for your comments. While this isn't the appropriate forum to get into all of your comments, I do take them seriously. I wanted to make a couple of quick comments and then would be happy to continue the discussion in a more appropriate forum.
With regards to the open issues/open pull requests that you mention. This is something we have been discussing in the Ansible public forums for awhile now. Long story short, we are going to be making some structural changes to the project to allow it to scale better. You can get some additional details here. (See: https://www.ansible.com/blog/thoughts-on-restructuring-the-ansible-project) This will be one of the major topics to be discussed during the Contributor Summit part of AnsibleFest in three weeks.
With your more specific issues, I have passed them along to the engineering manager for review to get them moving forward. We also have a number of public channels available to anyone to interface directly with the engineering staff at anytime for concerns, problems, etc just like these. Those channels are either #ansible-network on Freenode IRC or ansiblenetwork.slack.com. We certainly welcome you (or anyone else) to join us there to engage in such discussions or to use it as an avenue to make sure issues don't go unresolved.
Peter
4,000+ issues is quite a lot, Ansible is a pretty popular community-supported open source tool! :-) Talking to other community members really helps, since things can get lost in the shuffle with large open source projects like Ansible.
If you are a Red Hat customer, the best way is to file a support case and refer to the PR or Issue.
Hope this helps, and thanks for the comments and feedback! :-)
Andrius.