Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How to write a Neutron Plugin - if you really need to

Slides for the talk from Salvatore Orlando and Armando Migliaccio at the Openstack Summit - Fall 2013 in Hong Kong

Talk abstract:

  • Login to see the comments

How to write a Neutron Plugin - if you really need to

  1. 1. How to write a Neutron Plugin (if you really need to) Salvatore Orlando Armando Migliaccio
  2. 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. 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!!!
  4. 4. Part I The world of Neutron plugins
  5. 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. 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. 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. 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. 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
  10. 10. Part II Considerations for writing a new Neutron plugin
  11. 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. 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. 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
  14. 14. Part III Implementing a new Neutron plugin
  15. 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. 16. The HDN plugin - architecture Message bus (email) #TODO: Phone, Fax API request Neutron REST Interface Human-powered plugin engine
  17. 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. 18. Getting our hands dirty • Sources for the HDN plugin are available on github – – tested with gmail, should work with all SMTP servers
  19. 19. Summary
  20. 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???