The OpenStack Summit that took place in Atlanta two weeks ago is the first I’ve attended myself, so I gave myself some time to absorb my own experience and to read the subsequent press coverage before adding to the noise.
As I boarded my plane home, I tweeted: “Top 3 Q's I got asked at #openstack: 1) Roles of ODL vs Neutron? 2) How to make money in open source? 3) When will OpenStack be usable?” I’ll address #1 and #3 below…#2, of course, remains the multibillion-cowry shell question.
What should be the respective roles of ODL and OpenStack Neutron?
At the 10,000 foot level, it can sound like OpenStack Neutron and SDN controllers do more or less the same thing—provision and manage networks for cloud consumption. This has led to some discussion as to what should be done by which entity. Before jumping into the theorizing, though, it’s good to have an understanding of the current state of Neutron, the networking module for OpenStack. Rivka Little of SearchSDN provides a good summary, starting in paragraph 3 of this article. Most critically:
“Inside the cloud, Neutron works with virtual switches and hypervisors to configure ports and devices, and provision virtual overlays and tenants. But a Layer 3 agent is responsible for connecting these tenants out into the data center and the Internet. All traffic in a single cloud environment runs through that same L3 agent, which creates a choke point. That Layer 3 agent also lacks dynamic routing.”
That’s not to say, however, that OpenDaylight or other controllers are replacements for Neutron. Neutron is simply the newest portion of OpenStack and evolving rapidly. Meanwhile, a number of the developers working on Neutron are also working on OpenDaylight, especially on integration between the two projects. Rivka Little’s companion article, Do OpenDaylight and OpenStack Compete or Complement?, provides a good picture of the real focus of the discussion ,eg the appropriate degree of abstraction for Neutron.
Using OpenDaylight with OpenStack (slides and video with demo) gives a generic overview of how the two work together. For a more concrete picture, this demo shows how to instantiate and orchestrate some Vyatta vRouters with OpenStack and OpenDaylight.
Supporting Multi-Tenancy Between Data Centers
The SearchSDN quote above highlights a key use case for OpenStack: maintaining tenant connectivity and policy in clouds constructed from multiple physical data centers. Brocade has been working with Huawei on a proposal to do just that, which was shared at the Design Summit portion of the Atlanta event. You can read the blueprint here.
One of the blueprint authors, Mohammed Hanif, talks about it in this video:
This brings us to the “usability” questions: not When, But By Whom, For What?
First, some data points: I’m told there were virtually no actual user organizations at the summit a year ago. I don’t know the actual attendance breakdown in Atlanta, but anecdotally, roughly ¼ of the badges I had time to eyeball there were user orgs. Although the headliners (Walt Disney, Wells Fargo) are very large companies, most were not—something borne out in OpenStack’s own User Survey, which shows that 60% of deployments are in companies of under 500 employees. At the opposite end of the spectrum, most of the large, non-vendor organizations present were not large enterprises, but telcos. Which brings me to the point of this section.
Last fall, Geoff Arnold wrote a much-discussed post called Whither OpenStack, in which he debated whether it made much sense for enterprises to try to use OpenStack for private clouds. He also made reference to telcos having some specific needs of their own.
Consensus now seems to be emerging that there’s room for enterprises to develop and grow private clouds on OpenStack over time, especially with the certifications and hardened distributions that are now more firmly in place.
At the same time, NFV has seen remarkably rapid adoption in the telco space, and there’s clearly an appetite for using OpenStack to orchestrate those functions. Some additional work (slides) needs to be done within OpenStack to really support that, but we may well see a telco-centric body of work emerging over the next few months, with NFV at the core.
Late-breaking: a scrap over Fibre Channel in OpenStack
In a post last week, Stephen Foskett questioned whether there’s even a need to include Fibre Channel initiatives within OpenStack. J Metz responded this morning that it’s a moot question, since Fibre Channel is already implemented in OpenStack, with more proposals for Juno release. Instead, Metz says, “the question is related to the level and extent of which Fibre Channel can be managed and controlled by some type of orchestration layer using OpenStack infrastructure.” It’s a good question, and one that will be answered as users road-test it and OpenStack capabilities evolve.
In the meantime, if you’re curious where Fibre Channel is today in OpenStack, here’s a brief talk given by Andre Beausoleil on the FC Zone Management capabilities implemented in Icehouse.