Slides for the talk from Salvatore Orlando and Armando Migliaccio at the Openstack Summit - Fall 2013 in Hong Kong
Talk abstract: http://openstacksummitnovember2013.sched.org/event/c6478ecf54d639de3b8b9958bfe9d450#.UnLEI5ROpU0
HTML Injection Attacks: Impact and Mitigation Strategies
How to write a Neutron Plugin - if you really need to
1. How to write a Neutron Plugin
(if you really need to)
Salvatore Orlando
Armando Migliaccio
2. 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
3. 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 plugin
With code samples!!!
5. A Neutron plugin in a Nutshell
• Implements one or more “plugin interfaces”
• Receives requests from the API layer
API
API
request
AuthN
AuthZ
Validation
Dispatch
Plugin
Agents,
physical/virtual
appliances,
controllers, etc.
• Should NOT deal with authN/authZ
6. 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
Core Plugin
FW
Core
L3
Core Plugin
FW
Core
L3
FW
FW
Core
plugin
L3
FW
plugin
plugin
plugin
7. 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!
8. Making the right decision
• Implementing a driver vs.
a new plugin
• Adding a new service as an
extension vs. a service plugin
Tradeoff:
– Flexibility and interoperability vs simplicity
9. 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
11. Planning for a new neutron plugin
• Which extensions support
– At least L3 and security
groups for Nova integration
• Reusing Neutron’s
open source components
– DHCP agent, L3 agent, etc.
12. Developing a new Neutron plugin
• Backend synchronization
(pull vs push)
• Scalability
• High Availability
• Fault tolerance
• Unit and functional tests
• Extensions
– API and DB extensions
13. 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
15. 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
16. The HDN plugin - architecture
Message bus (email)
#TODO: Phone, Fax
API
request
Neutron REST Interface
Human-powered plugin engine
17. 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!
18. 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
20. • 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???
Editor's Notes
Explain also the three examples:Left – a single plugin implementing also extensions for L3 and Firewall services – refer to nicira plugin as an example of this kindCenter – A single plugin implementing core + L3 service, and distinct plugins for other services – this is what currently happens in deployments based on open source componentsRight – A distinct plugin for each extension; a schema that would be feasible from Havana as the L3 services can now be implemented in their own plugin
Bullet 1 – cite examples as ML2 driver or radwareLBaaS driverBullet 2 – cite examples as security groups or allowed address pairs or whatever extension you likeBullet 3 – Cite load balancing firewall and all this stuff. Remember that lines with bullet 2 are somewhat blurred because one could decide to go for a monolithic plugin approach and develop new services as extensions too.Bullet 4 – Cite ML2 as example
