QuantumAbstractPlugin

To define the Quantum plug-in interface, we will define a python class with all the methods that must be implemented in order to implement the plugin. All required methods will throw a "not implemented" error, similar to the network manager impl from nova.

During the summit we agreed that to start the plugin interface would map closely to the tenant API. Essentially, the API will parse the request, authenticate the request, enforce necessary limits, and hand the request to the plugin.

A common point of discussion during the summit was whether a plugin mapped one-to-one with a "type" of switch that could be managed (e.g., Open vSwitch, Cisco Nexus, etc.). A key point is that while a plugin may decide to only manage a particular type of switch, there is nothing that prevents a plugin from talking to multiple different types of switches to tie together interfaces plugged into different types of switches. It is even possible that a plugin could present a "driver" model that allows people to develop a standard interface for managing different types of switches using a uniform interface. This is POSSIBLE in the model, but not required.

As common functionality amount multiple plugins emerges, this can be shared among plugins in several ways:

• sharing the code among plugins using shared python modules as libraries
• extracting code from the plugin and putting it "above" the plugin layer (must be sure that ALL plugins need this functionality).
• sub-classing a base plugin class to that provides the common functionality.
• creating "meta plugins" that dispatch requests from the API layer depending on some criteria (e.g., interface-id type).