Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenStack: Netstack

Scalable Agent Detailed Design

 

 

OpenStack netstack RSS feed   Index | Next | Previous | View Threaded


gkotton at redhat

May 17, 2012, 6:09 AM

Post #1 of 8 (507 views)
Permalink
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 [at] lists
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp


kmestery at cisco

May 17, 2012, 6:18 AM

Post #2 of 8 (490 views)
Permalink
Re: Scalable Agent Detailed Design [In reply to]

On May 17, 2012, at 8: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


This looks great Gary. One comment: If the libvirt VIF type is set to "bridge" and you are using the LibvirtOpenVswitchVirtualPortDriver libvirt VIF driver, the VIFs are created by libvirt dynamically, and will be of the form "vnetN" instead of "tap<UUID>". We need to keep that in mind here, although I don't think it affects the proposal that much.

Thanks,
Kyle
--
Mailing list: https://launchpad.net/~netstack
Post to : netstack [at] lists
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp


gkotton at redhat

May 17, 2012, 6:28 AM

Post #3 of 8 (492 views)
Permalink
Re: Scalable Agent Detailed Design [In reply to]

On 05/17/2012 04:18 PM, Kyle Mestery (kmestery) wrote:
> On May 17, 2012, at 8: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
>
> This looks great Gary. One comment: If the libvirt VIF type is set to "bridge" and you are using the LibvirtOpenVswitchVirtualPortDriver libvirt VIF driver, the VIFs are created by libvirt dynamically, and will be of the form "vnetN" instead of "tap<UUID>". We need to keep that in mind here, although I don't think it affects the proposal that much.
Thanks for the comment. I'll check it out.
> Thanks,
> Kyle


--
Mailing list: https://launchpad.net/~netstack
Post to : netstack [at] lists
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp


hitesh.wadekar at gmail

May 17, 2012, 6:38 AM

Post #4 of 8 (492 views)
Permalink
Re: Scalable Agent Detailed Design [In reply to]

Hi Gary,

I'll check this more deeply. However, It looks great

Let me know if you need any help.

Thanks,
Hitesh Wadekar

On Thu, May 17, 2012 at 6:58 PM, Gary Kotton <gkotton [at] redhat> wrote:

> On 05/17/2012 04:18 PM, Kyle Mestery (kmestery) wrote:
>
>> On May 17, 2012, at 8: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<https://docs.google.com/document/d/1MbcBA2Os4b98ybdgAw2qe_68R1NG6KMh8zdZKgOlpvg/edit>
>>> Any comments and suggestions will be greatly appreciated
>>> Thanks
>>> Gary
>>>
>>
>> This looks great Gary. One comment: If the libvirt VIF type is set to
>> "bridge" and you are using the LibvirtOpenVswitchVirtualPortD**river
>> libvirt VIF driver, the VIFs are created by libvirt dynamically, and will
>> be of the form "vnetN" instead of "tap<UUID>". We need to keep that in mind
>> here, although I don't think it affects the proposal that much.
>>
> Thanks for the comment. I'll check it out.
>
> Thanks,
>> Kyle
>>
>
>
> --
> Mailing list: https://launchpad.net/~**netstack<https://launchpad.net/~netstack>
> Post to : netstack [at] lists
> Unsubscribe : https://launchpad.net/~**netstack<https://launchpad.net/~netstack>
> More help : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>


rkukura at redhat

May 17, 2012, 8:22 AM

Post #5 of 8 (481 views)
Permalink
Re: Scalable Agent Detailed Design [In reply to]

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 [at] lists
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp


irenab at mellanox

May 19, 2012, 11:44 PM

Post #6 of 8 (470 views)
Permalink
Re: Scalable Agent Detailed Design [In reply to]

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?
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?
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. I think this ties the agent and a plugin too much. 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.
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?
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?

Gary,
I will be glad to assist you with this blueprint.

Regards,
Irena

-----Original Message-----
From: netstack-bounces+irenab=mellanox.com [at] lists [mailto:netstack-bounces+irenab=mellanox.com [at] lists] On Behalf Of Gary Kotton
Sent: Thursday, May 17, 2012 4:10 PM
To: <netstack [at] lists>; 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 [at] lists
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp

--
Mailing list: https://launchpad.net/~netstack
Post to : netstack [at] lists
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp


gkotton at redhat

May 20, 2012, 12:13 AM

Post #7 of 8 (469 views)
Permalink
Re: Scalable Agent Detailed Design [In reply to]

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 [at] lists [mailto:netstack-bounces+irenab=mellanox.com [at] lists] On Behalf Of Gary Kotton
> Sent: Thursday, May 17, 2012 4:10 PM
> To:<netstack [at] lists>; 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 [at] lists
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp


dan at nicira

May 21, 2012, 6:29 PM

Post #8 of 8 (459 views)
Permalink
Re: Scalable Agent Detailed Design [In reply to]

On Thu, May 17, 2012 at 8:22 AM, Robert Kukura <rkukura [at] redhat> wrote:

> 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.
>

that's a clever idea...

dan



>
> -Bob
>
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack [at] lists
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp
>



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

OpenStack netstack RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.