<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 14 (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;
        font-family:"Calibri","sans-serif";}
@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">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">While keeping focused on defining proper approach to deal with Neutron third vendors’ plugin and driver, we also need to provide solution for complimentary
 critical piece of code maintained in the Nova code base.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Introducing new vif_type by neutron L2 Plugin/Driver, requires adding vif plugging support at Nova side.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I think it is very important to enable  virt driver  extensibility to support out of the tree/future vif_types.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">If the direction is to keep vendor plugins/drivers external to Neutron core, it seems reasonable to impose same policy on the Nova side.<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">BR,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Irena<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"><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""> Kevin Benton [mailto:blak111@gmail.com]
<br>
<b>Sent:</b> Friday, September 12, 2014 12:19 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Cc:</b> tanny.wu@huawei.com<br>
<b>Subject:</b> Re: [openstack-dev] [Neutron][Architecture]Suggestions for the third vendors' plugin and driver<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">> So my suggestion is remove all vendors' plugins and drivers except opensource as built-in.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Yes, I think this is currently the view held by the PTL (Kyle) and some of the other cores so what you're suggesting will definitely come up at the summit.  <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
> Why do we need a different repo to store vendors' codes? That's not the community business.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">> I think only a proper architecture and normal NB&SB API can bring "a clear separation between plugins(or drivers) and core code", not a different repo.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The problem is that that architecture won't stay stable if there is no shared community plugin depending on its stability. Let me ask you the inverse question. Why do you think the reference driver should stay in the core repo? <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A separate repo won't have an impact on what is packaged and released so it should have no impact on "user experience", "complete versions", "providing code examples",  or "developing new features". In fact, it will likely help with the
 last two because it will provide a clear delineation between what a plugin is responsible for vs. what the core API is responsible for. And, because new cores can be added faster to the open source plugins repo due to a smaller code base to learn, it will
 help with developing new features by reducing reviewer load.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, Sep 12, 2014 at 1:50 AM, Germy Lure <<a href="mailto:germy.lure@gmail.com" target="_blank">germy.lure@gmail.com</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, Sep 12, 2014 at 11:11 AM, Kevin Benton <<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
> Maybe I missed something, but what's the solution?<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">There isn't one yet. That's why it's going to be discussed at the summit.<o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="color:#38761D">So my suggestion is remove all vendors' plugins and drivers except opensource as built-in. </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#38761D">By leaving open source plugins and drivers in the tree , we can resolve such problems:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#38761D">  1)release a workable and COMPLETE version</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#38761D">  2)user experience(especially for beginners)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#38761D">  3)provide code example to learn for new contributors and vendors</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#38761D">  4)develop and verify new features</span><o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">> I think we should release a workable version.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Definitely. But that doesn't have anything to do with it living in the same repository. By putting it in a different repo, it provides smaller code bases to learn for new contributors wanting to become a core developer in addition to a
 clear separation between plugins and core code.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="color:#38761D">Why do we need a different repo to store vendors' codes? That's not the community business.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#38761D">I think only a proper architecture and normal NB&SB API can bring "a clear separation between plugins(or drivers) and core code", not a different repo.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#38761D">Of course, if the community provides a wiki page for vendors to add hyperlink of their codes, I think it's perfect.</span><o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">> Besides of user experience, the open source drivers are also used for developing and verifying new features, even small-scale case.<o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Sure, but this also isn't affected by the code being in a separate repo. <o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="color:#38761D">See comments above. </span><o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">> The community should and just need focus on the Neutron core and provide framework for vendors' devices.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I agree, but without the open source drivers being separated as well, it's very difficult for the framework for external drivers to be stable enough to be useful.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="color:#38761D">Architecture and API. The community should ensure core and API stable enough and high quality. Vendors for external drivers.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#38761D">Who provides, who maintains(including development, storage, distribution, quality, etc).</span><o:p></o:p></p>
</div>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Sep 11, 2014 at 7:24 PM, Germy Lure <<a href="mailto:germy.lure@gmail.com" target="_blank">germy.lure@gmail.com</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="color:#38761D">Some comments inline.</span><o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="color:#38761D">BR,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#38761D">Germy</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Sep 11, 2014 at 5:47 PM, Kevin Benton <<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal">This has been brought up several times already and I believe is going to be discussed at the Kilo summit. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#38761D">Maybe I missed something, but what's the solution?</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">I agree that reviewing third party patches eats community time. However, claiming that the community pays 46% of it's energy to maintain vendor-specific code doesn't make any sense. LOC in the repo has very little to do with ongoing required
 maintenance. Assuming the APIs for the plugins stay consistent, there should be few 'maintenance' changes required to a plugin once it's in the tree. If there are that many changes to plugins just to keep them operational, that means Neutron is far too unstable
 to support drivers living outside of the tree anyway. <o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="color:#38761D">Yes, you are right. "Neutron is far too unstable to support drivers living outside of the tree anyway". So I think this is really our important point.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#38761D">The community should focus on standardizing NB&SB API, introducing and improving new features NOT wasting energy to introduce and maintain vendor-specific codes.</span><o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On a related note, if we are going to pull plugins/drivers out of Neutron, I think all of them should be removed, including the OVS and LinuxBridge ones. There is no reason for them to be there if Neutron has stable enough internal APIs
 to eject the 3rd party plugins from the repo. They should be able to live in a separate neutron-opensource-drivers repo or something along those lines. This will free up significant amounts of developer/reviewer cycles for neutron to work on the API refactor,
 task based workflows, performance improvements for the DB operations, etc.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="color:#38761D">I think we should release a workable version. User can experience the functions powered by built-in components. And they can replace them with</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#38761D">the release of those vendors who cooperate with them. The community should not work for vendor's codes.</span><o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If the open source drivers stay in the tree and the others are removed, there is little incentive to keep the internal APIs stable and 3rd party drivers sitting outside of the tree will break on every refactor or data structure change.
 If that's the way we want to treat external driver developers, let's be explicit about it and just post warnings that 3rd party drivers can break at any point and that the onus is on the external developers to learn what changed an react to it. At some point
 they will stop bothering with Neutron completely in their deployments and mimic its public API.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="color:#38761D">Besides of user experience, the open source drivers are also used for developing and verifying new features, even small-scale case.</span><o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A clear separation of the open source drivers/plugins and core Neutron would give a much better model for 3rd party driver developers to follow and would enforce a stable internal API in the Neutron core.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="color:#38761D">The community should and just need focus on the Neutron core and provide framework for vendors' devices. Vendors just need adapt Neutron API and focus on their codes' quality. If not, I think the architecture
 is not proper. Everyone should only carry their own monkey.</span><o:p></o:p></p>
</div>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">On Thu, Sep 11, 2014 at 1:54 AM, Germy Lure <<a href="mailto:germy.lure@gmail.com" target="_blank">germy.lure@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal">Hi stackers,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">According to my statistics(J2), the LOC of vendors' plugin and driver is about 102K, while the whole under neutron is 220K.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">That is to say the community has paid and is paying over 46% energy to maintain vendors' code. If we take mails, bugs,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">BPs  and so on into consideration, this percentage will be more.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Most of these codes are just plugins and drivers implementing almost  the same functions. Every vendor submits a plugin,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">and the community only do the same thing, repeat and repeat. Meaningless.I think it's time to move them out. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Let's focus on improving those exist but still weak features, on introducing important and interesting new features.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal">My suggestions now:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">1.monopolized plugins<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">  1)The community only standards NB API and keeps built-ins, such as ML2, OVS and Linux bridge plugins.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">  2)Vendors maintain their plugins locally.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">  3)Users get neutron from community and plugin from some vendor on demand.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2.service plugins<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">  1)The community standards SB API and keeps open source driver(iptables, openSwan and etc.) as built-in.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">  2)Vendors only provide drivers not plugin. And those drivers also need not deliver to community.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">  3)Like above, Users can get code on demand from vendors or just use open source.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">3.ML2 plugin<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">  1)Like service and monopolized plugin, the community just keep open source implementations as built-in.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">  2)L2-population should be kept.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I am very happy to discuss this further.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">vendors' code stat. table(excluding built-in plugins and drivers)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">------------------------------------------------------------<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">Path                                                     Size<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">neutron-master\neutron\plugins\    63170<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">neutron-master\neutron\services\     4052<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">neutron-master\neutron\tests\             35756<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">BR,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Germy<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">_______________________________________________<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>
</blockquote>
</div>
<p class="MsoNormal"><span style="color:#888888"><br>
<br clear="all">
<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:#888888"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span style="color:#888888">-- <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:#888888">Kevin Benton<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><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>
</blockquote>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><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>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<p class="MsoNormal">Kevin Benton<o:p></o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><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>
</blockquote>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">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>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<p class="MsoNormal">Kevin Benton<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>