How to write a Neutron Plugin - if you really need to
-
Upload
salvorlando -
Category
Technology
-
view
23.752 -
download
4
description
Transcript of How to write a Neutron Plugin - if you really need to
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???