Sunday, October 25, 2015

Things good to know before the OpenStack Tokyo Summit.

OpenStack has a 6 months release cycle and each release is given a name in which the name is associated to the location where OpenStack Summit was held and follow the sequence of the English alphabet.  The 12th OpenStack release has the name Liberty and is officially available on Oct 15, 2015.

OpenStack Summit Tokyo will be held on Oct 27 - Oct 30 in Tokyo Japan.  On this weekend, a large portion of the OpenStack community is heading to Tokyo with excitement.  Even I am not able to attend this summit in Japan, I am excited to see what new technology innovation will be announced as well as the future direction of OpenStack.  (Note: OpenStack summit actually has 2 parts.  One part is the conference and the other part is the design summit where the open source community gather together to discuss and to shape the direction and/or feature of the next OpenStack release).

What's new in the Liberty release?

Liberty is the first release with the "Big Tent" approach.

Over the weekend, I have a chance to take a look at what's new in the Liberty release.  The most comprehensive and detail description of what's new in the Liberty is of course the release note from OpenStack.  If this is too detailed then Nick Chase (@NickChase) has an good article on the 53 things that are new in Liberty.  Also OpenStack has a very informative web page that describes the Liberty release.  There are 5 categories listed on this page as new features in Liberty:
  1. Enhanced Manageability
  2. Simplified Scalability
  3. Extensibility to Support New Technologies
  4. Container Management
  5. Orchestration
The categories are all self explanatory.  It is, however, interesting to see that container management is by a category by itself and is not under extensibility to support new technologies. 

In this post let me highlight a few things that interest me the most.

Most Useful

For me the new interface to display network topology - Curvature Network Topology interface in Horizon is the most useful to visual how the network looks like.  A sample display of this new interface is:
image source: https://www.openstack.org/software/liberty/

Hot Trend

There are 2 topics that are widely discussed in the IT industry and these 2 hot technologies are opening up new use cases and to help consumer either to save money or to deploy the services faster and easier.  These 2 hot trends are:
  1. Docker container
  2. NFV
OpenStack provide a natural infrastructures for these 2 technologies as well as a platform to bring out the essence or core features.

Docker Container

Docker containers need an orchestration engine to make it powerful and there are Docker Swarm, Kubernetes, CoreOS fleet that builds on etcd and systemd as well as Mesos.

In the OpenStack Vancouver summit there is a one day special track on container in which there is Project Magnum which was initially to work with Kubernetes in OpenStack and now the Container Orchestration Engine (COE) in Magnum is expanded to Docker Swarm and Mesos.

In July Google joined the OpenStack Foundation should be able to bring in their expertise on container and Kubernetes to the Magnum project.  I have a blog post on this subject. Also, the introduction of libnetwork brings new networking options to Docker container.

There are 2 new projects related to Docker Containers in the Liberty release:

NFV

The service provider industry is embracing NFV because it provides agility and huge cost saving advantages.  AT&T is said to have saved big on capex with NFV. There is the OPNFV project that is driving the advancement of open source NFV functionality and stability.

Both VMware announced vCloud NFV in VMworld Europe 2015.  Cisco also has it NFV offering.

Similar to Docker Container, NFV needs an infrastructure and OpenStack is a able to provide this need.

Interestingly, the effort of NFV in OpenStack is under the Nova project instead of Neutron as one might think.

Security

Role Based Access Control (RBAC) is added to both Heat and Neutron to provide better security on resource management and usage.

Security is essential to all projects and if OpenStack wanted to break into the enterprise market, security is an important element that needs to be addressed.  OpenStack already has a security group to handle security related issue in OpenStack.  Any bug fix that checked in has a SecImpact keyword to flag the OpenStack security group to look at potential security risk that is introduced in the code checkin.  There is also Project Bandit that can check for security issues in Python code in which OpenStack is written in.

Looking Ahead

I am excited to listen to the keynote and the YouTube recording of the various presentations from the OpenStack Tokyo summit. 

It will be interesting to see the future direction of OpenStack as decided by the community at the OpenStack Design Summit.

Another thing that I am looking forward to is to visit Japan and to try out the local ramen and the beer. 
image source: Gary Kevorkian of Cisco when he is at the OpenStack Tokyo Summit.


Wednesday, October 14, 2015

How are OVS, OVN, OVSDB and OpenFlow related?

We have seen these OVS, OVN, OVSDB and OpenFlow in various technology articles.  Do you know how they are related?  Or are they related at all?

Well, they all start with the letter "O", this will be great for a Sesame Street episode for us to learn words with the letter "O".  

They all start with the letter O because they are all have "open" in their name.

With "open" in their name, does that make them related?

OVS, OVN, OVSDB and OpenFlow are related but not because they have "open" in their name.

Before we look at how they are related let us take an overview of what they are and some of the key concept that we need to know.  We can only take an overview of OVS, OVN, OVSDB and OpenFlow in this post as they by itself can be one or more blog post to cover.


OVS


OVS is the short form of Open vSwitch.  It is an open source software based virtual network switching module that can be deployed on hypervisor such as KVM or white box switching hardware.   Detail description of OVS can be found on it homepage and GitHub page

A list of OVS feature can be found here.  The latest version is release 1.5

OVS is heavily used in OpenStack as KVM is the most deployed hypervsior for OpenStack while OVS is the default virtual switching module for KVM.

This diagram from OVS home page describe what OVS is:
image source: http://openvswitch.org/

As you can see both OpenFlow and OVSDB is related to OVS.  Will discus this in more detail later in this post.

 

OVN


OVN stands for Open Virtual Network and is pronounced as "oven".  This is why the logo looks like the front of an oven.  It is a sub-project within OVS.

Back in March 2015, I have already written an article on OVN.  Please refer to this post for OVN details.

OVSDB

OVSDB is a protocol. It stands for Open vSwtch Database Management protocol. It is used to manage an Open vSwitch. This is the management plan for Open vSwitch. It is defined in RFC 7047.

The heart of OVSDB is the database or schema that defines the configuration of the OVS as well as the QoS policies. Management module uses the JSON-RPC as the transport to communicate with the ovsdb-server module of the OVS. (note: JSON = JavaScript Object Notation and JSON-RPC is a Remote Procedural Call encode in JSON format).

OpenFlow

OpenFlow is a protocol.  It is one form of  control plane for Open vSwitch and is defined in RFC 7149.

The main idea is to setup flow table that defines the action of a particular flow.  The basic action types are forward and drop with other optional/recommended actions such as flood, enqueue or modify field.  

This diagram explains the Flow Table:
 

Putting OVS, OVN, OVSDB and OpenFlow together

This diagram summarize the relationship between OVS, OVSDB and OpenFlow

At this time OVN is part of OVS and uses the same interface ovsdb-server and ovs-vswitchd:

Summary

Both OVS and OVN are open source switching modules with OVSDB as the management plane and OpenFlow is used to program the flow from the controller to the OVS.