OpenStack and SDN - The neutron buzz !!

Lately, I have been reading quite a lot about OpenStack and all the buzz around neutron and SDN. You would find many links and a plethora of information online. This post is an effort to highlight or describe in simple words, the role of OpenStack neutron in connection to SDN. So without wasting any time, lets start.

We all know that Neutron is the OpenStack's project to offer Network as a Serivce - NaaS. Neutron started as a separate project after it was separated from nova-network.

With the growing interest in OpenStack, a lot of companies are making efforts to integrate their SDN solutions with OpenStack.

How are they (companies) doing it ?

The above figure is the answer to what the companies are doing. The top layer is the application layer which calls the neutron service APIs(1). The neutron service APIs are the APIs which are exposed to OpenStack services, say horizon (For example, when you do some network configuration from the OpenStack GUI). 

Between the neutron service API and physical layer, lies the neutron plugin.

To write a neutron plugin, the vendor/company/individual should adhere with the below rule:

1. Implement the interface called by Neutron service APIs(3).

Thus, at any point, interface 1 remains unchanged and the network function is realized using the same APIs - the neutron service APIs. This helps in keeping the application logic independent of the actual networking hardware.

Additionally, if a vendor wants to provide some additional functionality, he can provide several high-level APIs(2) via the API extension layer. These APIs also interact with the neutron plugin(3) to realize a high-level APIs(2) on the hardware. Using this, a vendor X can also integrate his switches with OpenStack solution. 

Companies are thus integrating their SDN solutions with OpenStack by means of neutron plugin. Refer this link to know more about various solutions available.

Writing OpenStack application - A simple example

Finally, after reading Brent Salisbury's post I got my OpenStack-ODL environment up and running. So, I thought of writing a small application on OpenStack using the novaclient.v1_1.client package.

Setup Environment:

• As described in this post till the line "The state of OVS after the stack should be the following:" [Just grep this line and do everything done before this.]
• 2 VM running instances namely test_vm1, test_vm
• The script should run on the Controller VM.

If you have your own setup, then you can take down the below details

• Python version 2.7.5
• Below packages need to be installed
• pip install python-keystoneclient
• pip install python-novaclient

Lets look at the below sample script.

  1 #!/usr/bin/env python

  2 import novaclient.v1_1.client as nvclient

  3

  4 # Replace the values below  the ones from your local config,

  5 auth_url = "http://192.168.56.104:5000/v2.0"

  6 username = "admin"

  7 password = "admin"

  8 tenant_name = "demo"

  9 project_id = "demo"

 10

 11

 12 nova = nvclient.Client(auth_url=auth_url, username=username,

 13                            api_key=password, project_id=project_id)

 14

 15 # Get the list of VMs

 16 srv_list =  nova.servers.list()

 17 server = nova.servers.find(name="test_vm1")

 18 print server

 19 print 'Rebooting server '+'test_vm1 ...'

 20 server.reboot()

 21 print 'test_vm1 rebooted'

Line 2 is used for importing nova package with.

Line 5-9 describe your local settings. When you run the controller node using devstack, you'll get the below output:

Horizon is now available at http://192.168.56.104/

Keystone is serving at http://192.168.56.104:5000/v2.0/

The IP Address here is the IP on which horizon service is running.

On line 5, the port number 5000 is used. You may also use port number 35357. Port 5000, 35357 are keystone's port numbers of public and administrative end-points.

For more details on port numbers, check this.

Line 12 is used to create a nova client object against which nova API calls would be made.

Line 16 and 17 are used to obtain the list of VMs and get the object of instance with name "test_vm1".

API call on line 20 finally reboots the instance.

Refer this to see the list of Server module APIs.

*********************************OUTPUT************************************

[fedora@fedora-odl-1 ~]$ python os_sample.py

[, ]

Rebooting server test_vm1 ...

test_vm1 rebooted

[fedora@fedora-odl-1 ~]$

Dashboard state before running the script.

After running the script os_sample, you'll see the rebooting message in the Power state column.

Acknowledgements:

This post is incomplete without acknowledging this wonderful link.