← Back to team overview

openstack team mailing list archive

Re: OpenStack Quantum plugins

 

On Fri, Apr 27, 2012 at 4:44 PM, Salman Malik <salmanmk@xxxxxxxx> wrote:

>  Hi Dan,
>
> Thanks for replying. There are few more questions:
>
>
>
> I am trying to learn the functionality of Quantum plugins used in
> OpenStack. I have read through the Quantum Admin Guide and had few
> basic/quick question about quantum and OVS interaction with it:
>
>
> 1) OVS can have ports in which vNICS can be plugged, so why does it need
> to use an integration bridge for connecting all VMs on the same node to a
> network?
>
>
> I'm not sure I follow what question you're asking.  When OVS is running on
> a host, it has one or more "bridges", and bridges have "ports".  A linux
> device representing the vNIC must be added as a port of a bridge being
> managed by the Quantum plugin.  We call this bridge the "integration
> bridge".   The Quantum plugin can then configure the ports and bridges
> appropriately to forward traffic based on the logical model created via the
> Quantum API.  Can you be more precise about what you're asking here?
>
> In short it means that the OVS is managing the linux bridges and the linux
> devices representing vNICs must be added to these bridges (Does Quantum
> manager adds these devices to bridges?).
>

You have to be a bit careful here, because the linux bridge and open
vswitch are two different things (you can think of open vswitch as an
advanced version of the linux bridge).

A driver in the Nova virt layer is actually the one who creates the linux
devices that map to vNICs.  For example, libvirt creates these devices as
directed by the libvirt driver code:
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py .
 This code attaches the linux device to an OVS bridge as a "port".  The
rest of the configuration of that port and the OVS bridge is up to the OVS
plugin agent.


> And when you say that quantum plugin configures the ports and bridges
> appropriately to forward traffic, you mean that it updates the database and
> then quantum agent then assures the correct mapping of ports/network ids to
> logical networks at the switch level(by adding flow entries to vSwitch? or
> by adding the vNICs to right bridges, as there is one bridge per tenant's
> network on compute node). Right?
>

Its not correct that there is one bridge per tenant network on the compute
node.  In the case of the OVS plugin, there is a single bridge (e.g.,
br-int) and different tenants are isolated based on configuration pushed
down by the agent.  Really the "plugin" consists of both the code running
on the server, and (optionally) agents running on the compute nodes.  Not
all plugins require agents, for example, if they have some other way of
managing the vswitch.



>
> Thanks for the reference. I have looked at the code and just to affirm my
> understanding please confirm/correct/answer the following:
> Quantum manager is responsible for configuring the network for new
> instances that spin up. When a tenant adds a port to his logical network
> the request will be forwarded to this manager by Nova and then Manager
> (using quantum client) would talk to quantum service/server (where can I
> see its code?) with the REST API. According to documentation, the quantum
> service is responsible for loading the plugin and passing the REST API
> calls to the plugin. The plugin then updates the database. Rest of the work
> is done by quantum agent.
>

See:
http://docs.openstack.org/incubation/openstack-network/admin/content/Using-dle455.html

The workflow is actually that you create a VM with one or more vNICs, and
as part of the VM creation process, nova-network is invoked using the
allocate_for_instance RPC call.  When you are running nova-network with
QuantumManager, this code uses the main Quantum REST API to create ports
for each vNIC.  This is the code I pointed you to before:
https://github.com/openstack/nova/blob/master/nova/network/quantum .
 Specifically, manager.py is the QuantumManager code, and
quantum_connection.py and client.py are libraries used to talk to Quantum's
REST API.

Dan


> Salman
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Follow ups

References