Currently, the one and only plugin selected is clearly not going to support all possible driver types. It will support 1 or more switch types by a specific vendor.
So it seems that Quantum developer API needs to move down a layer, so the one-and-only-plugin can talk to any driver type. Then drivers get registered in plugins.ini, not the q-plugin. I have been implementing a separate wrapper and driver, and following the return data in the openvswitch and cisco drivers (not the API docs). I like the idea of a common plugin that manages the global data structures, and handles the task list you described, and using a new API for drivers instead. Andy From: Dan Wendlandt [mailto:d...@nicira.com] Sent: Tuesday, September 20, 2011 12:10 PM To: Andy Bierman Cc: netstack@lists.launchpad.net Subject: Re: [Netstack] support for multiple plugins in Quantum On Tue, Sep 20, 2011 at 11:53 AM, Andy Bierman <bierm...@brocade.com<mailto:bierm...@brocade.com>> wrote: Hi, I am working on a Quantum plugin for Brocade switches. I noticed that if multiple 'provider' lines are specified in quantum/plugins.ini that quantum will use the last one and ignore the rest. What are the plans to support networking equipment from multiple vendors within openstack? Hi Andy, This gets to a common point of confusion with folks looking to extend Quantum: the difference between a plugin and a "driver" (unofficial term). Think of a plugin as a chunk of code that is responsible for accepting API calls like "create network", "create port", etc. Drivers on the other hand are device-specific code that know how to perform a particular task on a particular device (e.g., a brocade switch). You can definitely have a single plugin that communicates with different drivers to control different types of devices (the Cisco plugin has some examples of this, I believe). In my experience, it commonly breaks down this way: - the single plugin holds the logical network model and determines global state that applies across all switches (e.g., the VLAN being used to implement a particular network). - when nova schedules a VM workload in a particular location, the quantum plugin learns about the "binding" of that VM interface to a virtual/physical switch port. - the plugin invokes the driver specific to that virtual/physical switch along with global config state (e.g., a tenant VLAN) to perform the actual network configuration. The available plugins use a common code base for storing the logical data model and (if you choose) mapping it to a VLAN. It would likely be a pretty straightforward exercise for you to modify this code to work with a driver that talks Brocade switches instead of OVS or a Cisco switch. During the summit we talked about creating a plugin designed to simultaneously manage switches from multiple vendors by defining a standard driver interface in addition to the shared data model. I think the Cisco folks have taken some steps in that direction within their own plugin, so perhaps some of them can chime in. Dan Seems to me there needs to be a resource pool for switches, and when nova decides which compute node will host the VM, then 1 of the switches (maybe only 1) that is physically attached to that compute node is selected by quantum. Then the plugin for that switch is loaded (if it isn't already), and the plugin uses the switch(es) and port(s) that quantum tells it to use. Andy -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net> Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com<http://www.nicira.com> | www.openvswitch.org<http://www.openvswitch.org> Sr. Product Manager cell: 650-906-2650 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
