Hi Gary,
Thanks for taking up the work on improving the HA aspects of some of the agents. (I will respond to your review request once I get a chance to test the changes, but the diff looks good.) I agree with your assessment that the factoring of common agent code is probably a larger activity, and probably can be targeted as a separate patch. On your question regarding the need for an agent and if it can be done in the VIF driver - the VIF driver is not actually an independent thread of control, it gets executed as a part of the VM creation process. If a VM's VIF had to be always plugged into the corresponding port only when a VM was created, then I guess it would be fine to do the plugging from with the VIF driver. However, we also want to be able to support the use case that you can bring up the VM and then plug it into a port at a later time, or unplug and plug into a different network. In general, there is also a thought that the VIF driver should be really thin, and to the extent possible Quantum plugin-specific details should be pulled out it. Thanks, ~Sumit. From: netstack-bounces+snaiksat=cisco....@lists.launchpad.net [mailto:netstack-bounces+snaiksat=cisco....@lists.launchpad.net] On Behalf Of Gary Kotton Sent: Wednesday, April 25, 2012 12:55 AM To: netstack@lists.launchpad.net Subject: [Netstack] Quantum agents Hi, Sorry for not being able to attend the IRC meeting - it was in the middle of the night :) Whilst I was working on the integration of Quantum into oVirt I encountered a number of issues and challenges regarding the agents. Some of the issues were discussed in yesterdays meeting namely: 1. High availability 2. Scalability High Availability I discovered that when the agent was unable to access the database it would terminate on a exception. This has been addressed partially by https://review.openstack.org/#/c/6744/ (thanks to Maru Newby for the comments - updated, tested manullay for linuxbridge and ovs). I saw that Maru opened a bug regarding agent unit tests (kudos). I have tested the ovs agent and the linux bridge agent manually. I have yet to update the RYU agent (Isaku Yamahata suggested that we speak about this at the meeting). I think that we need to address this across the board and not only in the agents, but also in the plugins. The database access should be done via a common class that takes the connectivity into account. I do not feel that this is part of the bug fix above it is more of a system wide fix. Scalability This is a recurring topic. I understand that from the summit the idea of using AMQP came up. This still requires a "PUSH" from the plugin to the specific agent. After dealing with the agents above I wonder if we actually need the agents? Let me try and elaborate: when a VM is deployed the VIF plugin (I think that that is the terminology) creates the tap device, sets it to up and in the case of OVS notifies the integration bridge of the tap device. In the background the agent is running. When the agent discovers that the tap device exists and it matches a attachment from the database it "plugs" the device in and updates the database with the port status. Why not have the VIF plugin also do the interface plugin? This can and may solve a large number of scalability issues mentioned. This will be moving part of the logic from the agent to the VIF plugin. It would be intersting to know the rationale of the current implementation. Thanks Gary
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
