News Stay informed about the latest enterprise technology news and product updates.

Do OpenDaylight and OpenStack compete or complement?

OpenDaylight and OpenStack combine to enable IT as a service, but first the communities must wade through the overlapping features.

If both OpenDaylight and OpenStack can provision and manage virtual networks, and the two open source technologies work together, where does OpenDaylight stop and OpenStack begin? That's a question cloud pros grappled with at the OpenStack Summit last week -- but solid answers are still a work in progress.

"The division of labor is not clean right now. It is rapidly evolving," said David Meyer, CTO and chief scientist at Brocade, and chair of OpenDaylight's (ODL) Technical Steering Committee. "The way I look at it, OpenDaylight is the control piece and OpenStack will be in the orchestration domain. But right now, OpenStack wants to configure parts of the network, and that's where it's kind of messy."

OpenStack vs. OpenDaylight: Orchestration and network control are not the same

Messy it may be, but Meyer and many others say both sets of technologies are open source and work toward programmable, dynamic infrastructure, so it behooves the two communities to figure out how they complement each other.

While the two sets of technologies have some overlap, they also have different objectives that could end up complementing each other in the long run.

OpenDaylight's technology lets engineers decouple the control plane of the network, placing it in logical controllers that can granularly manage every flow. One of the ways controllers do this is by interacting with virtual switches to provision network overlays that allow for multiple tenants with accompanying services. But OpenDaylight goes a lot further, with the potential to change physical and virtual network management from the data center to the campus LAN.

Meanwhile, the OpenStack community has developed an open source cloud architecture that enables dynamic provisioning of storage, compute and networks to support cloud services. Key to that technology is Neutron networking, the platform that interacts with virtual switches to instantiate virtual network overlays and supporting services. But larger than that, OpenStack aims to jointly manage and provision storage, compute and network resources to support IT as a service, which requires gaining knowledge of all these IT resources and implementing policy across them.

Some see the division of labor being simply broken down between policy control for orchestration from OpenStack and deeper network control from OpenDaylight, with the two feeding each other information.

The ultimate goal would be to create a constant feedback loop between the controller and the orchestration tools. OpenDaylight would give OpenStack information about what's happening in the network, and using that, OpenStack would apply policy for provisioning. In turn, OpenDaylight controllers could carry out these orders.

For now, OpenStack doesn't have the ability to discover network resources the way OpenDaylight can.

"If you look at OpenStack, it solves one of the hardest problems of networking; 'How do you discover what's out there?' We flood networks to figure out where everybody is," said Brent Salisbury, senior software engineer at Red Hat and longtime ODL contributor." The ODL controller has the ability to tell every MAC address, IP address [and other] metadata that OpenStack can't yet do. I like Neutron; I like the APIs [application programming interfaces], but we don't have a data store yet."

But there becomes an issue of whether one defers to the other. Does the controller get dumbed down to carry out commands from OpenStack orchestration? Many network providers working with OpenDaylight are already beginning to build in their own orchestration or application-centric control features, so this may not make sense. On the flip side, do OpenStack developers limit their work in beefing up the networking features in Neutron?

"[On the] Neutron side, we are slowly building an SDN controller," said Chris Wright, technical director of SDN at Red Hat. "We have to look at where there is value in maintaining an API in Neutron to work with other controllers, or whether to bring more functionality into Neutron."

The division of policy implementation vs. network control also boils down to a difference in how users are able to interact with the technology through layers of abstraction.

OpenStack works at a higher level of abstraction than OpenDaylight. Developers, for example, can create and place apps in the cloud architecture through a layer of abstraction that shows them virtual network resources and policy, but not what's deep underneath in the inner-workings of the network. Meanwhile, SDN controllers go for a deeper level of network control.

"Let's have Neutron be responsible for abstractions that make sense to its users," said Lew Tucker, Cisco VP and CTO of cloud computing. Then implementation can be "deferred" to controller plug-ins.

In the coming months, as OpenDaylight and OpenStack add members and create code at a feverish pitch, a clearer definition of these abstractions and divisions of functionality will emerge. In the meantime, the two organizations are urging developers and networking pros to become involved in both organizations simultaneously to push the conversation forward.

Next Steps

What's possible withOpenStack networking?

OpenStack Neutron booed by IT pros

OpenStack security myths tackled

Getting to know Neutron networking

Dig Deeper on Software-defined networking