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.com@lists.launchpad.net [mailto:netstack-bounces+irenab=mellanox.com@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