On Thu, May 10, 2012 at 12:05 AM, Gary Kotton <gkot...@redhat.com> wrote:
> On 05/10/2012 12:55 AM, Sumit Naiksatam (snaiksat) wrote: > >> Hi Gary, >> >> Thanks for initiating this. A couple of comments/questions - >> >> 1. Do we really need the VIF driver to communicate the agent's identity; >> I am referring to the agent ID being sent by the VIF driver in the >> message? In general, I am not sure if there is a need to have the VIF >> driver send messages/notifications in the first place, but I perhaps >> it's being included as a capability in the framework? >> > At the moment the open source plugins are not aware of the agents. The > agents poll the data base for updates. The agent ID enables a agent to > regsiter with the plugin, this in trrun enables the plugin to send a update > to the specific agent. The update is initiated by the VIF driver. In my > opinion this does the following: > 1. updates the agents as soon as possible regarding a network change > 2. limits traffic on the network > 3. removes the database interface from the agents One important thing to note is that as we move toward achieving nova parity (which includes security groups, dhcp, port security, L3, NAT) the amount and type of data shared between the central node and the agents will take on many different forms. Many of the existing implementations that we'll be porting over from Nova rely on a central data store, and my feeling is that the fastest and least bug prone approach will be to have those agents continue to fetch data from the database. The biggest win we get from RPC is eliminating polling by notifying agents about changes via RPC, rather than having them poll the database to recognize that something has change. This is how Nova works as well, so I'd focus on using RPC in that fashion first. Dan > > 2. One model I was thinking of (which is kind of inline with the >> existing agent implementations), is where the agents are smart, and they >> know what to do in response to changes in the state of the logical >> Quantum resources. In such cases, the Quantum plugin need not have to >> keep track of sending a message to a particular agent. Instead, can we >> have broadcast messages from the plugin to all the agents? If the plugin >> has to unicast messages to specific agents, then it needs to maintain a >> lot more state/topology information which should not be mandated for >> this sole reason. >> > I too thought about this option. In a sense the above proposal is an > optimization of what you mention. This comes at the cost of complexity. The > broadcast option is nice when the number of agents is small. When this is > large, then for each network update there will be NUMBER_OF_AGENT messages > sent for each update. The advantage of what you mention is that the code is > self contained in Quantum. > > It may be better to start with the broadcast and then deal with the > optimizations afterwards. > > Thanks > Gary > > > Thanks, >> ~Sumit. >> >> -----Original Message----- >>> From: >>> netstack-bounces+snaiksat=cisc**o....@lists.launchpad.net<cisco....@lists.launchpad.net> >>> [mailto:netstack-bounces+**snaiksat <netstack-bounces%2Bsnaiksat>= >>> cisco.com@lists.**launchpad.net <cisco....@lists.launchpad.net>] On >>> Behalf Of Gary Kotton >>> Sent: Wednesday, May 09, 2012 4:27 AM >>> To:<netstack@lists.launchpad.**net <netstack@lists.launchpad.net>> >>> Subject: [Netstack] Scalable >>> Agents(https://blueprints.**launchpad.net/quantum/+spec/** >>> scalable-agent-<https://blueprints.launchpad.net/quantum/+spec/scalable-agent-> >>> comms) >>> >>> Hi, >>> I have added a very high level description on how to address the >>> >> issue. >> >>> This can be seen at: >>> >>> https://docs.google.com/**document/d/**1MbcBA2Os4b98ybdgAw2qe_** >> 68R1NG6KMh8zd<https://docs.google.com/document/d/1MbcBA2Os4b98ybdgAw2qe_68R1NG6KMh8zd> >> >>> ZKgOlpvg/edit >>> Comments will be greatly appreciated. >>> Questions: >>> 1. Do we want agents to be backward compatible (that is, still >>> >> maintain >> >>> the polling code) >>> 2. The generation of the Agent ID >>> 3. Any other ideas or thoughts about the matter? >>> I'd like to go ahead with a POC and implement this. >>> Thanks >>> Gary >>> >>> -- >>> Mailing list: >>> https://launchpad.net/~**netstack<https://launchpad.net/~netstack> >>> Post to : netstack@lists.launchpad.net >>> Unsubscribe : >>> https://launchpad.net/~**netstack<https://launchpad.net/~netstack> >>> More help : >>> https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp> >>> >> > > -- > Mailing list: > https://launchpad.net/~**netstack<https://launchpad.net/~netstack> > Post to : netstack@lists.launchpad.net > Unsubscribe : > https://launchpad.net/~**netstack<https://launchpad.net/~netstack> > More help : > https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp> > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
