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.
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.
The Juno release of Neutron will close the gaps on IPV6 support for tenant networks, allowing full IPV6 for tenant networks. We’ve added the capability for Neutron to manage the RADVD daemon to serve IPV6 RAs when required. For those looking to deploy Neutron in a pure IPV6 environment, you’ll find Juno allows for such deployments.
There are some well known issues around security group scaling with previous versions of OpenStack Neutron. In Juno, we’ve addressed these issues with two very important blueprints: The addition of ipset in lieu of iptables to manage security group rules on compute nodes, and the refactoring of the security_group_rules_for_devices RPC call. Both of these additions are meant to scale and dramatically improve the performance of the security groups implementations of Neutron.
We made some serious performance improvements in the L3 agent during Juno, as well as added the capability to have HA for the L3 agent. Both of these will help with users deploying the Neutron L3 agent. The HA work in particular means you can now have redundancy for L3 agents. As I mentioned earlier, the L3 agent is still required for SNAT traffic for DVR. So this improvement means there is no longer a single point of failure for that traffic when using the DVR solution. For deployers who choose not to use DVR, now you can have HA for all your L3 routing and NAT traffic as well.
I’ve just highlighted some of the many improvements we’ve made in Juno for Neutron. For information on more features, including new plugins and drivers, checkout the release notes. We’re excited by the work the Neutron community has done for Juno, and we’re looking forward to an exciting development cycle for Kilo as well!