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
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=cisco....@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco....@lists.launchpad.net] On
Behalf Of Gary Kotton
Sent: Wednesday, May 09, 2012 4:27 AM
To:<netstack@lists.launchpad.net>
Subject: [Netstack] Scalable
Agents(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
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
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp
--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp
