<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Managing the ports and plumbing logic is today driven by L2 Agent, with little assistance
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">from controller.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">If we plan to move that functionality to the controller, the controller has to be more
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">heavy weight (both hardware and software) since it has to do the job of L2 Agent for all
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">the compute servers in the cloud. , We need to re-verify all scale numbers for the controller<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">on POC’ing of such a change.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">That said, replacing CLI with direct OVSDB calls in the L2 Agent is certainly a good direction.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Today, OVS Agent invokes flow calls of OVS-Lib but has no idea (or processing) to follow up
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">on success or failure of such invocations. Nor there is certain guarantee that all such
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">flow invocations would be executed by the third-process fired by OVS-Lib to execute CLI.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">When we transition to OVSDB calls which are more programmatic in nature, we can
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">enhance the Flow API (OVS-Lib) to provide more fine grained errors/return codes (or content)
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">and ovs-agent (and even other components) can act on such return state more
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">intelligently/appropriately.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Vivek<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Armando M. [mailto:armamig@gmail.com]
<br>
<b>Sent:</b> Tuesday, June 17, 2014 10:26 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Neutron][ML2] Modular L2 agent architecture<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">just a provocative thought: If we used the ovsdb connection instead, do we really need an L2 agent :P?<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 17 June 2014 18:38, Kyle Mestery <<a href="mailto:mestery@noironetworks.com" target="_blank">mestery@noironetworks.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">Another area of improvement for the agent would be to move away from<br>
executing CLIs for port commands and instead use OVSDB. Terry Wilson<br>
and I talked about this, and re-writing ovs_lib to use an OVSDB<br>
connection instead of the CLI methods would be a huge improvement<br>
here. I'm not sure if Terry was going to move forward with this, but<br>
I'd be in favor of this for Juno if he or someone else wants to move<br>
in this direction.<br>
<br>
Thanks,<br>
Kyle<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
On Tue, Jun 17, 2014 at 11:24 AM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>> wrote:<br>
> We've started doing this in a slightly more reasonable way for icehouse.<br>
> What we've done is:<br>
> - remove unnecessary notification from the server<br>
> - process all port-related events, either trigger via RPC or via monitor in<br>
> one place<br>
><br>
> Obviously there is always a lot of room for improvement, and I agree<br>
> something along the lines of what Zang suggests would be more maintainable<br>
> and ensure faster event processing as well as making it easier to have some<br>
> form of reliability on event processing.<br>
><br>
> I was considering doing something for the ovs-agent again in Juno, but since<br>
> we've moving towards a unified agent, I think any new "big" ticket should<br>
> address this effort.<br>
><br>
> Salvatore<br>
><br>
><br>
> On 17 June 2014 13:31, Zang MingJie <<a href="mailto:zealot0630@gmail.com" target="_blank">zealot0630@gmail.com</a>> wrote:<br>
>><br>
>> Hi:<br>
>><br>
>> Awesome! Currently we are suffering lots of bugs in ovs-agent, also<br>
>> intent to rebuild a more stable flexible agent.<br>
>><br>
>> Taking the experience of ovs-agent bugs, I think the concurrency<br>
>> problem is also a very important problem, the agent gets lots of event<br>
>> from different greenlets, the rpc, the ovs monitor or the main loop.<br>
>> I'd suggest to serialize all event to a queue, then process events in<br>
>> a dedicated thread. The thread check the events one by one ordered,<br>
>> and resolve what has been changed, then apply the corresponding<br>
>> changes. If there is any error occurred in the thread, discard the<br>
>> current processing event, do a fresh start event, which reset<br>
>> everything, then apply the correct settings.<br>
>><br>
>> The threading model is so important and may prevent tons of bugs in<br>
>> the future development, we should describe it clearly in the<br>
>> architecture<br>
>><br>
>><br>
>> On Wed, Jun 11, 2014 at 4:19 AM, Mohammad Banikazemi <<a href="mailto:mb@us.ibm.com" target="_blank">mb@us.ibm.com</a>><br>
>> wrote:<br>
>> > Following the discussions in the ML2 subgroup weekly meetings, I have<br>
>> > added<br>
>> > more information on the etherpad [1] describing the proposed<br>
>> > architecture<br>
>> > for modular L2 agents. I have also posted some code fragments at [2]<br>
>> > sketching the implementation of the proposed architecture. Please have a<br>
>> > look when you get a chance and let us know if you have any comments.<br>
>> ><br>
>> > [1] <a href="https://etherpad.openstack.org/p/modular-l2-agent-outline" target="_blank">
https://etherpad.openstack.org/p/modular-l2-agent-outline</a><br>
>> > [2] <a href="https://review.openstack.org/#/c/99187/" target="_blank">https://review.openstack.org/#/c/99187/</a><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > OpenStack-dev mailing list<br>
>> > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> ><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>