openstack team mailing list archive

[Dan Wendlandt <dan@xxxxxxxxxx>]

On Sun, Apr 29, 2012 at 9:08 AM, Salman Malik <salmanmk@xxxxxxxx> wrote:

>  Thank you both for furnishing the references and providing great
> explanations. Though I had looked at some of them earlier, but now looking
> at them again with your explanations in mind, makes a lot of sense.
> However, there is one last question: I understand that the API client calls
> are made to the REST API server running at port 9696 (by default), but what
> I haven't yet understood is how these API calls are passed to/fro the
> Quantum plugin.
>
> After some searching through the Quantum plugins' code directory, I found
> a rest.py file in Ryu plugin directory that (seems to ) register handler
> functions with API server that may get called when API server receives a
> call, but I am not sure. Is it how the OVS plugin works as well? I mean
> does all plugin register callback functions with API server (just asking
> because I couldn't find anything similar in rest of plugins' code).
>

No, just look at the "Developing a Quantum Plugin" section of:
http://wiki.openstack.org/QuantumDevelopment .  Plugins get calls from the
main rest API by implementing the methods in quantum/quantum_plugin_base.py

dan


>
> Thanks,
> Salman
>
>
> ------------------------------
> Date: Sun, 29 Apr 2012 15:01:03 +0530
> Subject: Re: [Netstack] [Openstack] OpenStack Quantum plugins
> From: hitesh.wadekar@xxxxxxxxx
> To: salmanmk@xxxxxxxx; netstack@xxxxxxxxxxxxxxxxxxx;
> openstack@xxxxxxxxxxxxxxxxxxx
> CC: dan@xxxxxxxxxx
>
>
> Hi Salman,
>
> I think Dan explained pretty well, which will be covered all the quantum
> thoughts that you have asked me. There might be some code changes are going
> to happen for Folsom design feature implementation.
>
> Also, please have a look at here,
>
> 1. http://wiki.openstack.org/QuantumAPIUseCases
> 2.
> http://qconlondon.com/dl/qcon-london-2012/slides/SalvatoreOrlando_QuantumVirtualNetworksForOpenStackClouds.pdf
> 3.
> http://www.slideshare.net/danwent/quantum-folsom-summit-developer-overview
> 4.
> http://www.slideshare.net/danwent/openstack-quantum-intro-os-meetup-32612
>
>
>  If you go to Salvatore's 'Inside_Quamtum' 'slide, It provides quite a
> good deal of details concerning about How the nova interacts with Quantum.
>
> On the VIF driver side, that is a piece which runs in the nova address
> space, and tells VM being spawned how their VIF should be plugged into
> networks. There are VIF drivers for Quantum as well as VIF drivers for the
> other network managers. VIF drivers can be both plugin and hypervisor
> specific. For instance, nova/virt/<hypervisor_driver>/vif (e.g.:
> nova/virt/xenapi/vif).
>
> For OVS and more on Network, please refer this link,
> http://openvswitch.org/support/, go for
>
> 1. J. Pettit, J. Gross “Open vSwitch Overview,”
> 2. S. Horman, “An Introduction to Open vSwitch,”
>
> If you want to see advance networking virtualization, refer these papers,
>
> 1. J. Pettit, J. Gross, B. Pfaff, M. Casado, S. Crosby, “Virtual Switching
> in an Era of Advanced Edges,”
> 2. B. Pfaff, J. Pettit, T. Koponen, K. Amidon, M. Casado, S. Shenker,
> “Extending Networking into the Virtualization Layer,”
>
> I hope these will help. I am also exploring the code :) (still learner)
>
> Thanks,
> Hitesh
>
> On Sun, Apr 29, 2012 at 2:41 AM, Dan Wendlandt <dan@xxxxxxxxxx> wrote:
>
>
>
>  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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to     : netstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~netstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>


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