OpenContrail and OpenDaylight

On and off there is a discussion of potentially integrating OpenContrail with OpenDaylight. This may sound reasonable at 10,000 foot but once we look at the technology the problems become apparent.

First, lets start with what OpenContrail does:

  • OpenContrail provides a virtual network service to virtual-machines managed by an orchestration system such as OpenStack;
  • OpenContrail uses an orchestration system such as OpenStack to provide virtualized network services both to data-center virtual networks as well as L3VPNs.

The first challenge to integrate OpenContrail with OpenDaylight is that the later doesn’t have a VM scheduler that can start and manage virtual machines; it lacks some of the critical functionality of an orchestration system.

It is however attempting to solve the same problems that OpenStack already solves:

  • It is trying to provide services APIs competing with Firewall-as-a-Service, Load-balancer-as-a-Service, VPN-as-a-service APIs from OpenStack;
  • It is trying to enable multiple plugins that manage an underlay providing L2 services; a problem already solved by the OpenStack ML2 plugin.
  • It is attempting to decouple the virtual appliances service configuration from the network topology: a problem that OpenContrail already solves.

From a problem definition, it seems to me that OpenDaylight is in full collision course with OpenStack; the later has already solved the problems of how to integrate orchestration and network, specially if used with OpenContrail which allows the underlay network to be managed as a simple layer 3 network that doesn’t need to be managed.

One can always argue that it would be desirable to have neutral APIs for networking that are not tied to OpenStack; on CloudStack, the other orchestration system that OpenContrail integrates with, using OpenStack APIs isn’t really a big deal: the storage subsystem supports Swift for instance. And CloudStack by itself is already quite far along in solving the same problem: managing services independently of managing the network topology.

It is hard to understand the role of OpenDaylight unless it becomes a full fletched orchestration system; this is not such a bizarre idea as it may sound. Open source orchestration systems are still in their infancy when compared to proprietary systems that run large scale data-centers; current orchestration systems do a poor job of handling transient failures for instance: software failures in the compute-node always leave both my OpenStack and CloudStack clusters with VMs in wrong state that require manual reset.

At the moment, with OpenDaylight being a small subset of OpenStack/CloudStack it would be technically unfeasible to integrate OpenContrail.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s