PTL Overview: Juno to Kilo Roadmap in Neutron

Welcome to the PTL overview series, where we will highlight each of the projects and the upcoming features that will be in the next OpenStack release: Kilo. These updates are posted on the OpenStack Foundation YouTube channel, and each PTL is available for questions on IRC.

The following is a PTL webinar summary intended to provide an overview of the Juno to Kilo roadmap in Neutron.

At a high level, the networking program’s mission is to implement services and associated libraries to provide on-demand, scalable, and technology agnostic network abstraction.

Based on feedback from the Paris Design Summit, they realized a need to increase transparency and track priorities for Kilo in neutron-specs here.

“We’re focused around stability, scalability, and refactoring, which hopefully will bring better, more stable experiences for all the operators and deployers.”

This is how they plan to make that happen.

Achieving parity with nova-network

This work has been ongoing, starting with Icehouse and continuing in Juno, where features like DVR helped to close the functionality and feature gap between Neutron and Nova-network. With Kilo, the focus will be on migrating nova-network installs to Neutron.

There is also work around the edges of functionality. For example, DVR is likely to have VLAN support whereas in Juno, it only had tunnel network support.

REST / RPC / Plugin API Refactor

This is one of the big ticket items that has been an ongoing topic of conversation. In short, this is focused on making the core of Neutron more of an evolvable, scalable, and therefore stable, project.

They want to better support out of tree extensions (allowing more add-on support to Neutron), and switch homegrown WSGI to pecan.

REST / RPC / Plugin API etherpad

Plugin Decomposition

The goal is to thin the in-tree plugins and drivers that are upstream in the Neutron core project, allowing that functionality to be moved out into the plugin and driver maintainers’ preferred location. This addresses major pain points including review time, iteration speed, easy-to-use vendor specific modules, and more.

Plugin Decomposition etherpad

Testing

The Neutron team has spent a significant amount of time on testing. They are expanding to allow full-stack testing in the tree, functional testing of OVS, LB, DHCP and metadata agents, and retargetable functional tests.

Agent Refactoring

This works toward scalability and stability improvements.

Advanced Services Split

As part of thinning what’s in the Neutron core project itself, they decided to migrate LBaaS, VPNaaS, and FSaaS into separate git repositories.

This allows operators the flexibility of running the services they want to offer their tenants, allows the services teams the chance to iterate quickly outside the scope of core neutron, reduce gate testing complexity, and optimize the core parts of Neutron into a library.

Neutron Advanced Services Project Split blueprint

Pluggable IPAM

This has been a core topic at numerous design summits over the past 2 years, and the team hopes that this is the design cycle where it will really work.

They want to create a pluggable IPAM system inside of Neutron so that 3rd party and vendor IPAM systems can integrate with Neutron as well.

Pluggable IPAM blueprint

Speed and Reliability Improvements

These improvements are critical to deployers and operators.

• Agent Child Process Status: Monitors agents and restarts them when they exit (which provides more resiliency and peace of mind to operators)
• Rootwrap Daemon Mode: High performance access to root for commands run by Neutron agents

Flavor Framework

This provides a way for operators to offer network services to their clients, and a separation of driver functionality and configuration from consumers or services. It also allows operators to configure additional vendor features in an end-user agnostic way.

Neutron NFV Work

Working with the NFV sub-team in OpenStack, they’d like to see our trunk ports to virtual machines. They’d also like to more seamlessly connect hardware and neutron L2 segments.

New Plugins Proposed

Things Disappearing in Kilo

So far, the only plugin that a vendor or 3rd party has marked as deprecated is the Ryu Plugin — ultimately, the team behind Ryu has a replacement (ML2 + ofagent).

To see the full Kilo update from Kyle, be sure to check out the full webinar here:

Photo by markus spiske // CC BY NC