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). Thanks, Salman Date: Sun, 29 Apr 2012 15:01:03 +0530 Subject: Re: [Netstack] [Openstack] OpenStack Quantum plugins From: hitesh.wade...@gmail.com To: salma...@live.com; netst...@lists.launchpad.net; openstack@lists.launchpad.net CC: d...@nicira.com 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 <d...@nicira.com> wrote: On Fri, Apr 27, 2012 at 4:44 PM, Salman Malik <salma...@live.com> 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@lists.launchpad.net 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 : netst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
