Hi,
Please see my inline comments.
Thanks
Gary
On 05/20/2012 09:44 AM, Irena Berezovsky wrote:
Hi Gary,
Great document!
I have few questions and comments considering proposed design:
1.Agent to Plugin messages are RPC messages without any output expected (cast
messages). Am I right? Alternative approach can be triggering this via VIF
driver providing full set of information regarding the VIF?
From a previous discussion on the list the mantra is that the VIF
drivers should be as "thin" as simple as possible. Following Dan and
Sumit's comments, very basic VM operation can be implemented but looking
forward the network management could certain make things more
challenging - for example packet filtering, QoS, tunneling etc. In
addition to this the coupling between the VIF drivers and the agent
functionality could complicate things.
2. In the same section you talk about future method for network statistics,
this should be 'call' message. I do not quite understand why this message
should be called by Agent. For my understanding it should be triggered by nova.
What is the input/output for this? As you said in this section, Agent is not
aware of Network (only tap devices), so how does it retrieves the network
statistics?
I think that the agents should "push" their statistics to the plugin.
The plugin can aggregate the statistics and report to the user on
demand. In the case of the linux bridge the agents can read the
statistics from the bridge built for the specific network. In the case
of the OVS the agent can read via the ovs-vsctl API (maybe the command
is different but I think that it exists). The scope of the blueprint
does not address statistics, but this can easily be added.
There are a number of blueprints that can be implemented with this
infrastructure:
https://blueprints.launchpad.net/quantum/+spec/quantum-usage
https://blueprints.launchpad.net/quantum/+spec/linuxbridge-portstats-support
https://blueprints.launchpad.net/quantum/+spec/network-statistics
3. when you talk about 2 dictionaries that plugin maintains, you mention that
plugin will use tap-device name as a key to one of them.
The reason for the dictionary is that the agent does not have the
attachment or network UUID. In the case of the open source plugins the
agent only has the tap device name and the network name. the point of
the dictionary on the plugin side was to have a quick lookup to get the
relevant database key details.
I think this ties the agent and a plugin too much.
At the moment each plugin has their own agent. Currently there is not a
concept of a generic plugin and agents. This may be a nice idea in the
future.
In case you want to change a naming convention of VM net device, this will
require changes on the plugin side. This probably done in order to simplify,
but if you associate the VIF device during the VIF plugin phase, this can
communicate the key to the plugin and no plugin code modification required.
A change like this currently needs to be addressed in the following -
VIF driver will need to be updated and the agent will need to be updated.
4. Regarding the Network Update flow that you mention, I think that changing
VLAN tag for existing Network is quite a complicated case. Maybe this should be
handled by creating new Network with new tag, de-associating VM from old
network and associating with new one?
I do not think that this is complicated. The agent should be able to do
this without the user having to delete a network and create a new one. I
think that the blueprint
https://blueprints.launchpad.net/quantum/+spec/provider-networks deals
with this scenario.
5. Just a naming suggestion for network_details message. The message can be
called vif_network_profile. Message content can be called a network_profile:
vif_network_porfile: input parameters ( device name)
output parameters ( network_profile
dictionary)
6. when you mention that Agent can poll statistical information, can you please
say few words how/by whom this information will be used? What interfaces the
Agent should provide?
The open source agents have a loop. The agent can poll the relevant
statistics each second and report them to the plugin. I was just
addressing the infrastructure for the statistics. Each plugin can report
different statistics.
Gary,
I will be glad to assist you with this blueprint.
Thanks. I think that I am ok at the moment.
Regards,
Irena
-----Original Message-----
From: netstack-bounces+irenab=mellanox....@lists.launchpad.net
[mailto:netstack-bounces+irenab=mellanox....@lists.launchpad.net] On Behalf Of
Gary Kotton
Sent: Thursday, May 17, 2012 4:10 PM
To:<netstack@lists.launchpad.net>; Russell Bryant
Subject: [Netstack] Scalable Agent Detailed Design
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
--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp
