Yes, I think your view is correct. The web service API exposed by Quantum is for cloud tenants or cloud orchestrators (a different type of developer than you're talking about). Working toward a more standard driver model within a plugin would be nice, though I suspect really you will end up with drivers interfaces that are tied to particular assumptions about the single plugin maps logical networks to physical network (e.g., if the plugin maps a logical network to a VLAN in the physical network, you will need a VLAN driver for switch type X).
Dan On Tue, Sep 20, 2011 at 12:30 PM, Andy Bierman <bierm...@brocade.com> wrote: > 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> > 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 > Unsubscribe : https://launchpad.net/~netstack > More help : https://help.launchpad.net/ListHelp**** > > > > **** > > ** ** > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt > Nicira Networks, Inc. > www.nicira.com | www.openvswitch.org > Sr. Product Manager > cell: 650-906-2650 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~**** > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com | 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
