Jason Edelman's Blog
  • Home
  • About
  • Contact

Demo: Common Programmable Abstraction Layer

3/10/2014

12 Comments

 
Over the past few weeks, I’ve written about the idea behind a common programmable abstraction layer.  Previous articles are here and here.  It’s worth stating that something like a CPAL can be used with or without SDN controllers and with or without cloud management platforms.  As can be seen from the previous write ups and the video/demo below, today its primary focus is data extraction and data visibility.  It can use device APIs or controller APIs.  It’s about accessing the data you need quicker.  It’s that simple.  No more jumping from device to device and having to manage text and excel files.  

Edit 3/15/2014:
Github repo for CPAL

If there is a controller in the environment, you can still view data around particular physical and virtual switches in the environments by creating the right modules.  Same can be said if there was a CMP/CMS deployed.  While a CPAL can easily make changes to the network, it’s about taking small steps that can have a larger impact on how we use new APIs on network devices and controllers.  And if we don’t strive for a common framework now, we will end up with many more APIs than there are CLIs.  What good is that?
The first step is using these APIs for visibility.  Maybe in the future, the controller or CMP would actually use a CPAL API for provisioning – if not, it’s no big deal because there would still be a common framework for interacting with devices and getting the data needed.

Here is live demo of working with the CPAL.  If you are short on time, I’d ask you to take a look at the last 3 minutes working with tables.  
As always, feedback is welcome.

The code will be posted to git hub soon!

Edit 3/15/2014:
Github repo for CPAL

Thanks,
Jason

Twitter: @jedelman8

12 Comments
Stimit Oak
3/10/2014 06:10:40 am

Nice! This is super useful. Couple of questions:
-I assume this network is entirely in a virtual environment. How did you set up the individual devices? Did you have to code the agents that are running on the devices or are they built in to the vendor OS?
-Does having connected devices mean that the routing entries are already established in the individual devices? Is the assumption that each device is connected to each other device?
-I am actually an asic verification engineer. We use a systemverilog API to program the functionality in the switch asic (similar to what the SDK provides). So I am coming at this from a different perspective. Please excuse any stoopid questions I may have above.

Reply
Jason Edelman link
3/11/2014 04:05:36 am

Hi Stimit,
Thanks for the response.
1. It's using a virtual environment meant for onePK development. The routers are running vIOS. Another avenue would be to use VIRL/CML from Cisco. The Arista device is a virtual appliance based switch. Very handy for dev work.
2. They are embedded agents in each vendor's offering. I'm exploring the idea of creating my own agent actually since many vendors are offering the ability to load LXCs or native apps into the OS. What are your thoughts on this?
3. No assumptions around connected devices. As long as the py shell has connectivity to the device.
4. No stupid questions! They were great questions :)

Reply
Michael
3/10/2014 06:18:20 pm

Hey Jason,
nice work. Are you doing this all by yourself? what's your final goal with this?

Reply
Jason Edelman link
3/11/2014 04:07:45 am

Hello Michael,
Thanks. Yes, flying solo right now! However, a few great ppl are reaching out to contribute, so it may expand from being just me.
As far as a final goal, I have some ideas, but the key is to baseline the need, feasibility, and if it's something that'll actually be used by customers :)

Do you have thoughts or recommendations for a project like this?

Thanks again!
-Jason

Reply
Will Dennis
3/11/2014 12:58:37 am

Nice stuff. What IOS is running on the Cisco devices? (I see the term screen references onePK) Also, what method is used for authentication?

Reply
Jason Edelman link
3/11/2014 04:10:22 am

Hey Will, thanks for commenting. It's running vIOS! :). Using VIRL/CML may be a better long term for development. I'm hiding the un/pw when in the device class for each device type, but they are pretty much using a privileged level 15 local uname/pw on both the Cisco and Arista devices. FWIW, both have the option to be encrypted as well.

Reply
Will Dennis
3/11/2014 10:32:55 am

So does vIOS integrate onePK API's? Or is access via an "expect"-like command set?

VIRL/CML would probably be great when it's released, but still vaporware as of now... You using GNS3 at the present?

Jason Edelman link
3/12/2014 02:39:30 am

Will, answering your question from below - blogging platform doesn't allow to go more than 3 deep for some reason.

vIOS is running with an embedded onePK agent. The cpal library is only using the onePK SDK - No expect here. I can get VIRL/CML if I wanted to for onePK development, but just haven't done it yet. This post has more background on the APIs: http://www.jedelman.com/1/post/2014/02/the-power-of-a-programmable-abstraction-layer.html

Reply
Steven Iveson
3/11/2014 01:31:19 am

Jason,

I'm sure everyone agrees this has huge potential. Whilst I support the use of a CLI I can also see a GUI being more useful for some tasks too. I can see a GUI with a heirarchical list of devices (and/or device groups) where you can simply click on a device and based on what it is get a routing table, arp table, mac table etc. Either way the possibilities are endless.

I'd concur that simple show command type visibility is the best first step. If you do plan to expand this I'd hope you'd have a long hard think about the command structure and the like and not just duplicate what you see with Cisco et al.

I can't really code (yet) but I'd be happy to contribute around the CLI and command structure and/or adding the F5 REST API to the mix perhaps?

Awesome stuff.

Reply
Jason Edelman link
3/11/2014 04:20:57 am

Steve,

I appreciate you thinking everyone agrees this has potential. For one, I clearly do! But I've given the demo to a few folks now and I've heard things like "this makes things more complicated" and in other cases, they clearly see the power of what it can offer.

I'm debating on GUI vs. CLI now, but for mass usability, GUI+CLI will make sense. Building the GUI isn't just technically hard, but it's more important to get the abstractions and pre-built functions right because the key here is, by just using the Python Shell, this is not an application per se, it's a just a GREAT tool to programmatically work with devices. That said, this can also be used to build an app like you suggest. As more ideas emerge, maybe it can turn into something big!

You've written a great series on PP, what do you mean you can't code yet!!! We all can. I still say I can't either!

Great feedback on command structure - agreed, and if you have any recommendations on structure, I'm all ears! And yes, adding F5 APIs is an awesome idea. You can contribute any way you'd like. It'll be good to gather the ideas and then stare at a whiteboard for a few hours to plan the way forward!

Thanks for great comments.

-Jason

Reply
Steven Iveson
3/11/2014 06:29:03 am

Lol, perhaps I should have added "with Python" :-)

Great to see you're very open to ideas and comments.

Regarding the CLI/command structure, it may be overkill at this stage but this article (and particularly the first attribute) lays out my view and throughts very well: http://packetpushers.net/the-attributes-of-a-great-cli/.

I'd love to get involved and doing something useful as a motivation to pick up Python (as well as do more interesting things with F5) would be great so please do get in touch when that's a possibility.

Cheers

Stuart Fordham link
5/12/2014 10:19:05 pm

Jason, this is great stuff, but a bit of a noob question - once I do a git clone, how do I actually get libraries to work in Python?

Cheers

Reply



Leave a Reply.

    Author

    Jason Edelman, Founder & CTO of Network to Code. 


    Enter your email address:

    Delivered by FeedBurner


    RSS Feed


    Categories

    All
    1cloudroad
    2011
    2960
    40gbe
    7000
    Arista
    Aruba
    Big Switch
    Brocade
    Capwap
    Christmas
    Cisco
    Controller
    Data Center
    Dell Force10
    Embrane
    Extreme
    Fex
    Hadoop
    Hp
    Ibm
    Isr G2
    Juniper
    Limited Lifetime Warranty
    Meraki
    Multicast
    N7k
    Nexus
    Nicira
    Ons
    Opendaylight
    Openflow
    Openstack
    Presidio
    Qsfp
    Quick Facts
    Routeflow
    Sdn
    Sdn Ecosystem
    Security
    Ucs


    Archives

    May 2015
    April 2015
    February 2015
    January 2015
    December 2014
    November 2014
    October 2014
    September 2014
    August 2014
    June 2014
    May 2014
    March 2014
    February 2014
    January 2014
    December 2013
    November 2013
    October 2013
    September 2013
    August 2013
    July 2013
    June 2013
    May 2013
    April 2013
    March 2013
    February 2013
    January 2013
    December 2012
    November 2012
    October 2012
    June 2012
    May 2012
    April 2012
    March 2012
    February 2012
    January 2012
    December 2011
    November 2011


    View my profile on LinkedIn
Photo used under Creative Commons from NASA Goddard Photo and Video