I recently had the honor of being on the OVS Orbit podcast. Ben Pfaff has been doing these shows for a short time, and I was happy to join him and discuss open source development processes as they relate to Open Source networking projects. One key note which Ben calls out is something I firmly believe in, and wanted to quote and paste below: Kyle’s advice: plan ahead, research the projects, give your developers time to become comfortable with the projects, treat everyone with respect, treat everyone equally, and give back to the core of the project.
[Updated 6-2-2015 with the full process for filing RFEs in Neutron.] Starting with the development of the Juno release, the Neutron project moved to using a specs repository similar to how other projects were using them. In our quest to enforce a waterfall design model, we also added an appropriate spec template which was filled with things such as “Problem Description”, “REST API Impact”, “IPv6 Impact”, “Community Impact”, and everyone’s favorite sections on “Testing” and “Documentation.” We deployed this with the best of intentions and the greatest of hopes.
One of the most interesting new features in Neutron for the Kilo release is the addition of subnetpools to the API. This work was initially targeted to integrate nicely with pluggable IPAM. Unfortunately, this did not make it into Kilo and is targeted at Liberty. But even without pluggable IPAM as a consumer, the subnetpools addition is quite useful. Here’s an example of how you might use it. neutron net-create webapp neutron subnetpool-create –default-prefixlen 24 –pool-prefix 10.10.0.0/16 webpool neutron subnet-create –subnetpool webpool websubnet What I’ve shown above is the creation of a network, pool, and subnet for an example web application.
As we near the end of the OpenStack Kilo release, I wanted to take a moment to write about a few things around Neutron’s Kilo release. In a lot of ways, Kilo was all about continuing to scale the development model for Neutron going forward. We did accomplish some feature work, as well as a lot of technical debt repayment. But the main focus was on how to continue evolving Neutron the platform.
We’re nearing the end of the Kilo development cycle. This is typically where the rubber meets the road, as we’re trying our hardest to merge a lot of code near the end. It’s a fairly busy part of the cycle. I wanted to take a moment to write about two efforts which will help to scale Neutron development in Kilo and beyond. The Kilo cycle has involved a couple of efforts which are meant to expand and scale the Neutron development community.