Earlier this year, Kyle Mestery posted an article on his blog outlining some common misconceptions about contributing to the Neutron project and how to contribute effectively upstream. Kyle is a Senior Director and Chief Technologist for Open Source Networking at HP where he is responsible for technical vision, strategy, and development for open source initiatives. He also works on OpenStack, OpenDaylight, and Open vSwitch. He is also Program Technical Lead (PTL) for the OpenStack Neutron project, the networking component of OpenStack handling the complex task of connecting machines in a virtual environment.
Find out more about Kyle and his work prior to his talk at the OpenStack Summit in Paris this year in this interview.
What sort of reactions did you get from your post, and what else have you learned since taking over as Neutron PTL (program team lead)?
In Neutron, we have an interesting dichotomy of participants. We are heavily vendor-focused, which means we have a lot of people with potentially competing interests. My hope in writing the blog post earlier this year was to educate not only the Neutron community but also new participants in the broader open source community on how to be successful with their open source contributions. I received positive feedback from many people and had some very meaningful conversations as well. We're about to start the Kilo development cycle, so my hope is I was able to affect positive change for everyone who contributes to not only Neutron but also any other open source project.
The main lesson I've learned since becoming Neutron PTL is the fact that running a large scale open source project involves utilizing not only engineering skills, but also project management skills and people management skills. Trying to move a large ship like Neutron in the right direction is a full time job. I love the fact I have the privilege of being elected to this job, and I work hard with all of our community members to ensure they are successful. Ultimately, a project is defined not only for the code which is produced, but also by the people and relationships built while producing that code. Having a healthy community is something which drives the long term health of a project. These are all things which are obvious when you think about them, but when leading an open source project, these become the core tenants of how you interact with everything you do.
Another lesson I've learned is that change can be good. In OpenStack, we're constantly evolving the project, both in terms of technical decisions, but also in terms of governance. And we do this by making slight tweaks to the project and governance, trying things out and then evaluating how that worked, keeping the parts which worked well and abandoning the parts which didn't work well. The end result is a very dynamic project which is always evolving forward in a positive direction, changing as it needs to.
The last lesson I've learned, though certainly an important one, is that in a project like OpenStack, user input is a critical piece of our development cycle. The OpenStack project has done an increasingly awesome job of gathering user input and ensuring users are involved at all stages of the development cycle. In Neutron, we've made changes during both Juno and Kilo to ensure we capture as many user requirements as early as we can. In Juno, we moved to using a neutron-specs repository which clearly outlined user requirements in the template spec. In Kilo, we've updated the neutron-spec to more clearly place user requirements near the top. This was done to remind anyone submitting specs to capture these user requirements clearly at the beginning. Asking yourself how will someone use this, or how will this change affect current users, helps to ensure a positive user experience.
Is there anything in the recent Juno release that you're particularly excited about?
The Neutron team focused hard in Juno on working to finish achieving parity with nova-network. An important part of this was the change we made to implement Distributed Virtual Router (DVR) functionality. This work allows us to distribute both L3 routing and Destination NAT (DNAT) functionality to each compute host. This removes the need to use a separate L3 network node for this functionality. SNAT is still done on the central network node, but to alleviate the single point of failure, we also implemented L3 HA functionality. This allows for redundancy for SNAT when using DVR, or for people who do not want to utilize DVR they get redundancy for all their routing, DNAT and SNAT functionality.
Besides OpenStack, what's your favorite open source cloud project?
Outside of OpenStack, I have two favorite open source cloud projects: OpenDaylight and Open vSwitch. OpenDaylight is a project shepherded by the Linux Foundation to build a community driven Software Defined Networking (SDN) controller. I've been participating in this project since it was conceived early in 2013. In fact, I'm also an OpenDaylight Ambassador, which means I present at technical conferences on OpenDaylight, most typically with how you can use it with OpenStack Neutron. The second project I love working in is Open vSwitch. Open vSwitch is at the core of most Linux based cloud deployments as the virtual switching element. I've been working in Open vSwitch for 3 years or so. Working on all three projects gives me an end to end view of how this all works at an architectural level, which is very helpful. Plus, each community is great to work with. I am very fortunate to have contributed to releases for each project, as well as having made great friends in each community.
Can you describe the intersection of OpenStack and OpenDaylight to the layman to better understand the relationship between cloud and controller?
One way to think about how each of these works is to look at what they are providing. Neutron itself has a built in reference implementation which utilizes agents and RPC calls to handle programming virtual and physical switches. OpenDaylight has been built so it can utilize many different southbound protocols (OpenFlow, NETCONF, SNMP, etc.) for doing the same. The Neutron team has worked hard to stabilize and scale the in-tree reference implementation, and we've done a great job doing that. The OpenDaylight team has been doing the same with their implementation of the Neutron API. When the two work together, you end up with Neutron being an API and DB layer, along with hooks into things like nova (for VIF plugging) and keystone (for authentication). OpenDaylight is now responsible for interpreting API requests into programmable logic on each virtual and physical node. And OpenDaylight can now be scaled separately from Neutron. The two work together to satisfy virtual networking for tenants.
How does working on an open source project like OpenStack improve the relationship between companies who might otherwise be seen as competitors?
This relates to the blog post I wrote, but it boils down to the fact that you have to be willing to compromise if you want to have success. Compromise here means allowing others to shape your creation and idea. It means allowing competitors to become invested in your idea. A great idea presented as a complete solution is doomed to fail as an open source project. A great idea presented as something needing collaborators, with an earnest interesting in gathering collaborators, will succeed. As soon as you let your idea go and grow on it's own, the faster it will take root and blossom. This is a key piece of advice which many do not grasp and struggle with.
See the full series of OpenStack Kilo Summit speaker interviews.
1 Comment