Peter Sprygada needs no introductions. His presentation on the afternoon of day 2 at NFD18 was the highlight of day 2.
He spent good two hours in RedHat offices in Sunnyvale (CA), flooding us with his usual enthusiasm talking about Ansible Network Engine and its exciting new features that are just round the corner.
What Ansible is not
There is such a lot of confusion around what Ansible is, where most of the people I talk to think it’s the jack of all trades, that magic wand that fixes all your problems and makes you live a better life.
Peter spent a good 10 minutes of his talks admirably wiping away all of that.
Ansible is NOT SDN, is NOT an orchestrator, but just a wrench (and a very powerful one) in your toolbox.
Ansible Network Engine
Ansible NE is a new thing. And I believe it’s something that whoever used Ansible to automate networks always dreamed of having. NE is a set of “functions” distributed as Ansible Roles to oversee and take care of various phases of the lifecycle of your network.
The delivery model of NE is also decoupled from the main Ansible codebase, with much faster release cycles compared to the main Ansible core.
An Ansible Network function provides an abstracted way of interacting with network gear that takes away the complexity of having to deal with a multi-vendor environment.
“Create a VLAN”. That’s all you need to know.
Ansible and Openconfig
A very interesting feature the folks at Ansible are working on at the moment is an easier and simpler way to work with YANG and OpenConfig.
If you ever tried to configure a device using open config, two of the most challenging issues you have to address are:
- which models does your device support
- put together a json template for Ansible to populate with variables
This is exactly what the new Ansible openconfig role is meant to fix. Get the supported YANG models straight from the device and spit out a json file that is the “template” that you have to hydrate and send back to your device for the configuration to happen.
Ansible ML2 plugin for Openstack
The virtual networking landscape was dominated until very recently by SDN controllers programming OpenFlow entries into the vRouters in the hypervisors through OVSDB.
Recently the advent of different models (such as the EVPN control plane for VXLANs) changed things quite drastically, whereby now the network overlays are driven by the configuration plane (an EVPN L3VNI is – in the end – something you configure on the ToR switches).
When all of this is bundled with an Openstack deployment there’s something that needed covering.
What happens if a tenant creates an EVPN-based overlay in Neutron? Who configures the ToRs?
Ansible seems to have an ML2 plugin for Openstack that can action some playbooks (or Network Functions – I should say) whenever a specific network is created on Neutron.
Looking forward to learn more about this.
toolr.io 
Leave a Reply