Not all APIs are created equally.

Automation is starting to become the new catch phrase in the networking Industry. It seems like 2014 is the year that marketing groups from different vendors have been touting APIs on their products. Skeptical networking engineers however have claimed that an API does not mean that their jobs are getting easier. In fact it’s been making their jobs a little harder.

Before a networking engineer could strictly focus on pure networking. But now, network engineers are increasingly required to know more and more on how to code or at least know how to read code.

Just because you have an API doesn’t mean all the devices can and will play nice with each other. 

We can see this by looking at three different platforms. 

OpenStack         Contrail        Junos

Now let’s look at their API for data retrieval/configuration

REST                  REST           Netconf

Ok now you have two platforms that use one type of API and a third platform that uses a different API.

Let's look at the resulting Data Structure response

JSON                JSON XML

Again we have two platforms that have the same Data Structure and a third with a different Data Structure.

You might say, ok, at least two of these platforms have the same API and with the same data structure things should be good for both of them right? Actually as they say, the devil is in the details.

I can illustrate this just by looking at a simple IPv4 subnet. 

On Openstack the data abstracted looks like this

{ "networks": [ { "contrail:subnet_ipam":  [  { "subnet_cidr": "12.1.1.0/24",  } ] } ] }

On Contrail it looks like this

{"virtual-network":{ "network_ipam_refs":[ { "attr": { "ipam_subnets": [ { "subnet": { "ip_prefix": "12.1.1.0", "ip_prefix_len": 24 }, } ] }, } ], } }

You can see that one platform combines the subnet with the mask while the other one separates it. For a DevOps engineers and Network Engineers this is annoying. It’s like having to learn different Network Operating systems. The goal of an API should be to allow a simplified abstraction layer.

APIs need to be standardized. Openflow is a good attempt at this. Openflow requires the underlay to have a common protocol in order to allow a controller to programmatically configure them. The networking industry has done a great job at standardizing protocols but a sorry job at creating a common API standard. Maybe the IETF needs to jump in on this. A standardized API could ultimately make our jobs that much more easier.

Using python to connect remotely to Openstack

In order to beef up my DevOps skills I decided to see if I could connect through a REST API using python. I found out that there are some python modules built specifically for this.

One such module is called novaclient. You would need pip on your machine to do this.

sudo easy_install pip

Then you can use pip to install the nova client.

sudo pip install python-novaclient

If you want to look at the details of the python module it can be found here:

https://github.com/openstack/python-novaclient

This is where I look more into the code and found out it’s capabilities

You can pass parameters to the “client” function.

def __init__(self, username=None, api_key=None, project_id=None,

auth_url=None, insecure=False, timeout=None,

proxy_tenant_id=None, proxy_token=None, region_name=None,

endpoint_type='publicURL', extensions=None,

service_type='compute', service_name=None,

volume_service_name=None, timings=False, bypass_url=None,

os_cache=False, no_cache=True, http_log_debug=False,

auth_system='keystone', auth_plugin=None, auth_token=None,

cacert=None, tenant_id=None, user_id=None,

connection_pool=False, session=None, auth=None,

completion_cache=None):

First I built a login function that will pass these parameters which I can call from my main script.

login.py

-----------

def get_nova_credentials():

 cred =  {}

 cred['username'] = "admin"

 cred['api_key'] = “password”

 cred['auth_url'] = "http://<openstack-ip>:5000/v2.0"

 cred['project_id'] = "demo"

 cred['service_type'] = "compute"

 return cred

Now in my main script I can import the client and my credentials

server-list.py

-----------------

#!/usr/bin/env python

import novaclient

from novaclient.v1_1 import client

from login import get_nova_credentials

credentials = get_nova_credentials()

#Pass credentials to the client function.

nova = client.Client(**credentials)

#grab the list of servers and print out the id, names and status

vms = nova.servers.list(detailed=True)

for vm in vms:

  print vm.id, vm.name, vm.status

—————

script in action.

laptop$ python server-list.py 

f5801333-5d81-496c-b257-e589ca36e944 Cirros-VM2 ACTIVE

098270e0-e5fb-4ea6-a1f1-2dfca11a409d Cirros-VM1 ACTIVE

So what's the big deal? Why do this when you can use the Horizon web ui?

Now that I have a basic understanding of this module, I can start automating things such as building VMs, virtual networks, etc in a scaled and precise manner.