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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
