More Related Content
Similar to How to write a Neutron Plugin - if you really need to (20)
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!!!
- 4. Part I The world of Neutron plugins
- 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
- 10. Part II Considerations for writing a new Neutron 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
- 14. Part III Implementing a new 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
- 19. Summary
- 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
- #7: 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
- #10: 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