Neutron Liberty Midcycle In Fort Collins
I just got back from the Neutron midcycle, and wow was there a lot of exciting work and conversations that happened at the HP office in Ft. Collins Colorado.
Changing perceptions
Neutron’s mission, in my view, is to provide an expressive, abstract API that allows users to provision networking resources without being locked into a vendor. Neutron should be capable of taking logical resources like networks, subnets, ports, IP allocation pools, load balancers, firewalls, and other well known network functions and implement them in a deployer’s technology of choice.
There are currently two networking solutions in the OpenStack space, and for a number of years the two communities that were in charge of these networking solutions were not collaborating. To me it felt like there was always friction.
In some ways, this shirt says it all.
In my opinion, one of the major stumbling blocks for Neutron’s acceptance in the wider OpenStack community has been perceptions by some that the project actively takes choices away from users when it comes to selecting networking gear, networking technologies, and even the type of networking topologies that are supported.
In a lot of instances, the reason why Neutron struggled to gain acceptance was the lack of good documentation, that could help clear up misconceptions and rumors that made the rounds in the OpenStack community.
Fixing perceptions with the networking guide
The release of the networking guide has made a huge impact in helping improve the perception of Neutron in the wider community. There have been multiple conversations where I have been able to say that yes, Neutron is able to do the kind of networking topology that you need for your use case, or no, neutron can’t do exactly what nova-network does, but we have a pretty close alternative that you can take a look at and consider.
While there are still gaps that need to be addressed, the ability to point people to excellent diagrams and documentation, I think has helped remove a lot of the concern people had about Neutron. A lot of concern about Neutron was based on not quite knowing how it works. Neutron is a complicated piece of software, and it is natural to be concerned about how it actually works. Not everyone can spend two years (like I did) reading the actual code, so that they can they feel confident about it. I tried in many cases to document the internals of Neutron as I learned them, but it was still not enough. We needed something that someone could sit down in an afternoon and read, without the code in front of them, and walk away feeling reasonably confident about how Neutron works.
Neutron Linux Bridge mechanism driver testing
In order to make Neutron more versatile, usable in more use cases, and fight a misconception that Neutron takes away choices from users, the Linux Bridge mechanism driver needs to be tested and supported the same way the Open vSwitch mechanism driver currently is.
At the Neutron midcycle, I worked with Anita Kuno, Sean Dague, and Doug Wigely (who helped me with my terrible Bash skills) to put the final touches on some patches to DevStack to help get the Linux Bridge mechanism driver to the point where it could begin running as a continuous integration job in the OpenStack jenkins cluster (commonly known as The Gate).
This is a very important item, since at the Vancouver summit, testing the Linux Bridge mechanism driver was one of many items that the Neutron community committed to delivering in Liberty, as a good-faith gesture that the Neutron project is serious about working with the nova project and building a future together.
Installation guide restructuring
Matt Kassawara also stopped by during the midcycle, so Doug Wiegley and I had a discussion with him about the installation guide. Currently, the installation guide has two sections for installing a networking solution.
- A basic networking architecture
- A more flexible networking architecture
The basic networking architecture is currently implemented with nova-network, but in our discussion at the midcycle we determined that it is also possible to deploy Neutron in a way that also satisfies the basic networking architecture case.
Summary
I had a great time at the midcycle. To be honest I almost prefer them to the summits since the pace is not nearly as frantic, and we can spend time on specific pieces of work.