On 05/17/2012 09:09 AM, Gary Kotton wrote: > Hi, > Please see the link for a detailed design of the scalable agent > solution. I plan to start to work on the actual implementation beginnig > of next week. Please let me know if you have any comments and or > suggestions. Please note that I have used all of the comments and > suggestions from over the last few weeks. > https://docs.google.com/document/d/1MbcBA2Os4b98ybdgAw2qe_68R1NG6KMh8zdZKgOlpvg/edit > > Any comments and suggestions will be greatly appreciated > Thanks > Gary >
I've got two comments after a quick read, and may have more later: 1) I suggest following nova's lead on the default RPC backend. If nova still defaults to rabbitmq, I don't see any need to add qpid to the set of things devstack needs to manage. Distributions can choose their own defaults. 2) The following open issues are identified at the end of the document: > Open Issues > > Python 2.4 support (XEN DOM0 Agent support) > Do we still want to continue to support the agent polling > Do we want the VIF drivers to invoke the “update event”. One possible way forward for XenServer would be to run the agents in the same domain as the nova compute server instead of in dom0 with python 2.4. The VIF driver "update event" would be used to notify the agent of a new tap device, rather than requiring the agent to poll dom0 to detect new tap devices. Finally, as I hinted at during the IRC meeting, the existing "rootwrap" mechanism, or something like it, could be configured to allow the agent to remotely execute commands in dom0. -Bob -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
