My Appearance on the OVS Orbit Podcast

Neutron RFE Process

Subnetpools in Neutron

Neutron Kilo Retrospective and a Look Toward Liberty

Scaling OpenStack Neutron Development

Now that we’re past a very busy December which included the Neutron mid-cycle in Lehi, Utah, the Neutron Spec Proposal and Approval Deadline, the Kilo-1 release of Neutron, as well as some holiday’s enjoyed around the world in December, I thought it was time to take a moment and blog about where we are in Neutron, and some of the important changes coming in the Kilo release. These changes will affect everyone from developers to deployers, from operators to packagers. I’m hoping the information I’m sharing here will spark some conversations around these ideas for people who may have only heard passing information on them.

This is just a quick post to note that the devstack support for OpenDaylight was recently updated to use the Helium release of OpenDaylight. For anyone who wants to pull down devstack and have it spin-up Neutron with OpenDaylight, you will now get the latest and greatest OpenDaylight release as a part of this. My blog post on how to use this is still relevant, so if you’re looking for instructions please look there.

As I was recently given the chance to serve as Neutron PTL for a second cycle, I thought it would be a good idea for me to share some insight into what I’m hoping to achieve upstream in Kilo. I’ll have some upcoming posts on what we’re planning on accomplishing, but I wanted to first start with a post about the actual people who are allowed to merge code into Neutron, the core reviewers.

As of today, we just published the second Juno release candidate for Neutron. The expectation is this will be the final RC candidate and will become the official 2014.2 release of OpenStack Neutron. I thought I would take a moment to highlight some of the awesome work done by our community during the past 6 months.

Distributed Virtual Router

By far one of the largest, if not the largest, features we added as a team was the addition of Distributed Virtual Router (DVR) functionality. The team working on this has spent multiple cycles iterating on this code, and it finally landed in Juno. This is an exciting development because in prior versions of Neutron, the default L3 routing behavior was to send all traffic to L3 network nodes for routers. Clearly this presents issues around single points of failure on those L3 network nodes, not to mention the issue around having those L3 nodes become traffic bottlenecks. With DVR, routing functionality is distributed to each compute node, removing the need for a central L3 network node for this functionality. NAT functionality is also distributed in a similar manner. SNAT, however, is still centralized. The reason for this is due to the requirement of burning an IPV4 address on each compute node in a distributed SNAT environment. The wiki listed above has many more details on the DVR architecture.

If you’re a fan of networking, you are no doubt very excited by all of the recent excitement in the industry as of late. And there is no larger area of innovation in networking at the moment than Open Source networking. Two of the projects at the forefront of Open Source networking innovation are OpenStack Neutron and OpenDaylight. OpenStack Neutron is driving an API around networking for Infrastructure as a Service Clouds, and has been very successful at driving mindshare in this area. There are a large number of Plugins and ML2 MechanismDrivers for Neutron in existence already. However, so far, there is no OpenDaylight integration with OpenStack, at least upstream. I am pleased to announce that a team of us are working on making this happen, however. We have a blueprint filed and we are actively working towards the support in OpenDaylight required to support the Neutron APIs. What I’m going to show you in this blog post is how to take what we currently have for a test run and try it out yourself.