Using CallManager APIs for fun and profit: Part 2 - Python

In this part 2 of my API adventure, i will be looking at repeating what we did Part 1 via SoapUI in python using the suds library.  If you haven't read that yet, then really, please go back and do that. This will not be wildly useful otherwise.

Getting SOAP-y with Python suds

Yeah I went there...

So, we have a process that allows us to programatically look stuff up. Only its not very repeatable, and therefore not much use yet.  With this post I will take you through the creation of a python script that mimics what we did previously - finding things, and showing them to you.

For brevity, I am not going to take you through setting up Python and installing suds.  With respect, if you can't figure that out yourself, you probably shouldn't be playing with this stuff anyways.  Its also a post in and of itself, and plenty of others have covered it well.  I am also using Ubuntu for this work.  You can use OSX pretty much interchangeably since its all *NIX based.  Windows will work, but I warn you now, its quirky.  Obviously I don't provide any sort of warranty with anything I do here, and whilst I will try to help people who feedback about problems via windows, my initial response will probably be, "can you not use linux instead?"

So. Much like when we talked about the 4 sections of the SoapUI request, we will look at 4 sections of our Python script

1. modules
2. required variables
3. API "proxy object" creation
4. obtaining data via the proxy object

Using CallManager APIs for fun and profit: Part 1 - SoapUI

This is one of those posts that I will constantly refer back to... ;)

In my day job it's clear to me that we need to automate more and more of the dumb day to day stuff.  One of those things is Leavers and Starters on our phone system.  

We employ Cisco CallManager, much like the rest of the world, and if you have ever spent any time with it, you will know that its VASTLY over-complicated to manage.  A single extension on someones' desk requires (at least); 

• an End User object
• a Device Profile (extension mobility)
• a Phone object
• a Voicemail profile

In order for these to exist and function you need access to appropriately configured 

• Device Pools, 
• Calling Search Spaces, 
• Partitions, 
• Regions,
• Clusters
• Gateways

All of this ends up being at least one person's full time job once you get over a certain level of employees. 

There are various functions within the standard Web GUI including the entertainingly named "SuperCopy" which cuts the admin burden from about 40 mins per user of manual click-type, to about 20 mins.  A valuable 50% saving in time, but that's still 20 mins of click-type that we could all do without. 

There is however, a rather rich (read: confusing) API for CallManager called AXL, which with the right amount of time and dedication can be tamed.

Over the past 2 weeks I have been mulling over my own SuperCopy scripts in python, with a view to swapping the 20 mins of click-type for 10 questions and 10 seconds.  The right hand page will be to add phone provisioning into our existing Account Setup automation over AD, thus eliminating all manual operations for leavers and starters entirely.  If it works, we look to gain an entire head in our team back on a full time basis to focus on break/fix and engineering improvements - a MASSIVE win.

I have said before, that the role of the Network Engineer is moving further and further away from fingerbashing CLIs.  If you cannot embrace APIs and scripting, then its my job to tell you that you are making yourself obsolete. Fabrics and flows are already replacing the classic tree architectures and packet based switching.  Our jobs are no longer about making things work and more about optimising whats there.  APIs and automation are how we as engineers stay ahead of the curve, and in employment.  On top of all of that, its more fun as well...

The SDN Conundrum...

Oh how the world has changed since I started out in the wonderful trade.

We used to have VLANs and subnets; switches, routers and firewalls.  People would moan things didn't work and we did a traceroute to figure out why.  We would bash out a fix, and if it broke, we would bash out another.  It was the wild west, and that was fun.  Cowboy hats were standard issue.

Then along came the bad guys, and with them, the policy doctors.  Changes became more structured and requirements became more complex.  Environments spiraled out into wider geographical areas and management became less about break fix and more about tightly structured architecture.  The industry responded with protocols and toolchains, each with their own use case, and bit by bit, the sector split up into the key areas of WAN, DC and Campus.

Product portfolios splintered and expanded, use cases became more and more tailored and expansive, until now, most enterprise network admins have hundreds of devices in geographically diverse locations, each with their own subtle differences.  They tend to adhere to policies, and usually templates, but the nature of the beast today is that no two unique devices are configured truly the same.

End result is that managing enterprise networks, which almost always encompass all three key areas, is no trivial task.  To counter this, management have to invest time and money into training and drills to ensure that engineering changes are tightly controlled, and defining standards to as far as possible enforce uniformity into the environment.  The net result tends to be simplified troubleshooting (win), at the cost of slower mean time to delivery and diminished capability for rapid reaction to events (lose).

This is surely not a one size fits all summary, but i'd be surprised if some if not all of that rings true to a large amount of my peers today.

Again, the industry has responded.  In this, the era of devops and scripting, many vendors have looked to enable automation into their equipment, however, automation isn't new.  SPs have been taking CSV files and regexing templates for TFTP delivery since the 90s.  The first batch of automation we have seen recently has been an extension of that - essentially allowing machine control of the CLI, without that interim step of regexing a config template.  Big whoop. The configs still diverge from the template over time and all we have done is decrease rollout times.  Management and Maintenance is in no better shape.

The true leap forward has been with a phrase that fills most old school engineers (me included) with fear and trepidation - Software Defined Networking (SDN).