How to write a Neutron Plugin(if you really need to)

Salvatore OrlandoArmando Migliaccio

Who are these guys talking to us?• Salvatore (the fat one)

– Core Openstack Neutron developer– Breaking Openstack since Cactus– Known by @taturiello on twitter and salv-orlando on IRC

• Armando (the fit one)– Core Openstack Neutron developer– Contributing code since Bexar– Fixes Salvatore’s code– Know by @armandomi2001 on twitter and armax on IRC

• They are both employed by VMware and happily (w)hack neutron code on a daily basis

Summary

• Part I: What is a Neutron plugin? Do you really need a new one?

• Part II: Design choices when writing a Neutron plugin

• Part III: Writing your first Neutron pluginWith code samples!!!

Part I

The world of Neutron plugins

A Neutron plugin in a Nutshell

• Implements one or more “plugin interfaces”• Receives requests from the API layer

• Should NOT deal with authN/authZ

API

Plugin

Agents, physical/virtual

appliances, controllers, etc.

AuthNAuthZ

ValidationDispatch

API request

Core and service plugins

– Core: Implements the “core” Neutron API(L2 networking + IPAM)

– Service: plugin provides additional network services (Eg.: load balancing, firewall, VPN)• network services can also be provided by core plugin by

implementing the relevant extensions

API

Plugins

Core L3 FW

Core Plugin

Core L3 FW

Core Plugin

Core L3 FW

Core plugin

L3 plugin

FWplugin

FWplugin

Plugins with drivers

• Can execute a given request on different backends; actual execution is delegated to a driver– ML2

• Openvswitch, linuxbridge, hyper-V, tail-F NCS, Arista, …

– Load Balancing reference plugin– Firewall reference plugin– (soon) VPN reference plugin

• Implementing a driver is much easier than implementing a whole plugin!

Making the right decision

• Implementing a driver vs.a new plugin

• Adding a new service as anextension vs. a service plugin

Tradeoff:– Flexibility and interoperability vs simplicity

Available options

• Integrate some kind of network device into Neutron– Driver (for ML2, LB, FW, etc.)

• Add a feature that applies to existing API resources– API extension and plugin support

• Provide a new network service, “orthogonal feature”– New service plugin

• New integrated solution or new paradigm– New core plugin

Part IIConsiderations for writing a

new Neutron plugin

Planning for a new neutron plugin• Which extensions support– At least L3 and security

groups for Nova integration

• Reusing Neutron’sopen source components– DHCP agent, L3 agent, etc.

Developing a new Neutron plugin

• Backend synchronization (pull vs push)

• Scalability• High Availability• Fault tolerance• Unit and functional tests• Extensions– API and DB extensions

Contributing a new Neutron plugin

• Meet certain standards– Provide thorough unit test

coverage– Provide documentation

• And then more documentation

– Think Devstack– Tempest– Think Smokestack

Add your own funny image here

https://wiki.openstack.org/wiki/NeutronDevelopment#Developing_a_Neutron_Plugin

Part III

Implementing a new Neutron plugin

Introducing the HDN plugin

• HDN: Human Defined Networking• Rediscover the human face of IT– REST API requests are transformed into emails

sent to the networking guy in your IT department– Asynchronous, eventually consistent, request

processing– Karma-based request prioritization; the nicer you

are to the IT guy, the sooner your requests will be processed

The HDN plugin - architecture

API request

Neutron REST Interface

Message bus (email)#TODO: Phone, Fax

Human-powered plugin engine

Implementing the plugin

• Core API– Support for networks, ports, and subnet

• Supported extensions– L3: Support for routers and floating IPs– Admin extension for notifying request completion

• Other neutron extensions– Outside scope… at the end of the day you can

always pick up the phone and call your IT guy!

Getting our hands dirty

• Sources for the HDN plugin are available on github– https://github.com/salv-orlando/hdn– tested with gmail, should work with all SMTP

servers

Summary

• Consider all your alternatives before making a choice on whether developing a plugin, an extension or a driver

• When developing a new plugin check if and how it should integrate with the various neutron agents

• Make your plugin verifiable through unit and integration testing

• Open source all the things, but document them as well

• Who needs SDN when you have HDN???