<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=us-ascii">
<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;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Courrier New";}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
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;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle20
{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:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
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 Dan,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Regarding the live migration I'll start separate thread.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Regarding the SR-IOV, please see inline.<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""> Dan Wendlandt [mailto:dan@nicira.com]
<br>
<b>Sent:</b> Wednesday, July 25, 2012 8:18 AM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> Re: [openstack-dev] [Quantum] Re: Some thoughts about scalable agent and notification<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi Irena, <o:p></o:p></p>
<div>
<p class="MsoNormal">On Sun, Jul 22, 2012 at 5:25 AM, Irena Berezovsky <<a href="mailto:irenab@mellanox.com" target="_blank">irenab@mellanox.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi Young, Gary, Dan,</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I am not sure that my concerns are directly related to the thread subject, but they are related to
the thoughts raised by you.</span><o:p></o:p></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">1.</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Providing compute_host data as part of the 'create_port' can help the Plugin if it requires VM physical location knowledge. On the other hand, Plugin can 'discover' VM compute_host
data by querying OS API.</span><o:p></o:p></p>
</div>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">2.</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">What is the live migration flow that currently implemented between Nova and Quantum? As far as I understand nova does not call Quantum at all. The only work is done by Agents.
Agent at the destination host will connect VM tap device and Agent at the source host will disconnect VM tap device. Adding call to Quantum for compute_host data update can be very helpful. Otherwise Agent notification can be used for getting new Host info
update.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Yes, you are correct. Currently there is no webservice API for indicating the hypervisor that will be hosting the workload, and instead plugin itself is responsible for learning about these locations (note: this sometimes takes the form
of an agent, but could just be an OpenFlow controller with no local agent). <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">3.</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">If VM vNIC should be provisioned using SR-IOV technology, the exact Virtual Function data should be put into DOMXML; so it can be only VIF Driver and not Agent. Since some
sort of VF resource management should be implemented per Host, maybe this means that Vif Driver should call Agent for VF allocation. But I think it was decided to avoid such sort of communication.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">I believe the Cisco vif-plugging logic makes (or at least used to make) a webservice API to an API extension to grab some info required for the libvirt XML. I think that's OK. My main goal is that the vif-plugging logic be simple, so
that we don't end up shoving a bunch of network complexity in nova. In the example you're mentioning, is the libvirt interface xml type=direct? If so, perhaps we want to create a standard interface driver for type=direct that makes a generic webservice call
to fetch the required parameters. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#1F497D">For my understanding for SR-IOV there will be a device section in VM XML, like:<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:10.0pt;font-family:"Courrier New""><</span><span style="color:#1F497D">hostdev mode='subsystem' type='pci' managed='yes'><o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="color:#1F497D"> <source><o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="color:#1F497D"> <address domain='0x0000' bus='0x05' slot='0x00' function='0x1'/><o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="color:#1F497D"> </source><o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="color:#1F497D"> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/><o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="color:#1F497D"> </hostdev><o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="color:#1F497D">I think that there is no interface section at all.<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="color:#1F497D">So it interesting how to provision it with Quantum, since vNIC are allocated once VM is powering up (by guest driver) on top of Virtual PCI device.
<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>
<div>
<p class="MsoNormal">Dan<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><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:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks a lot,</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Irena</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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""> Dan Wendlandt [mailto:<a href="mailto:dan@nicira.com" target="_blank">dan@nicira.com</a>]
<br>
<b>Sent:</b> Friday, July 20, 2012 12:23 PM<br>
<b>To:</b> <a href="mailto:gkotton@redhat.com" target="_blank">gkotton@redhat.com</a><br>
<b>Cc:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> [openstack-dev] [Quantum] Re: Some thoughts about scalable agent and notification</span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi Yong, Gary, <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt">Please put [Quantum] in the subject line for such emails, so it is easier for team members to filter. I've edited the subject in this case. More thoughts inline. <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Fri, Jul 20, 2012 at 12:30 AM, Gary Kotton <<a href="mailto:gkotton@redhat.com" target="_blank">gkotton@redhat.com</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi,<br>
Please see my comments below.<br>
Thanks<br>
Gary<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
<br>
On 07/20/2012 03:07 AM, Yong Sheng Gong wrote: <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Verdana","sans-serif""><br>
hi,<br>
I think the workflow can be this:<br>
1. nova quantum api: allocate_for_instance(compute_host, device_id)<br>
2.quantum-server: create_port(compute_host, device_id), we need to extend port model to include compute_host</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I think that this is problematic in a number of respects:<br>
1. not sure how this will work for live migration (that is moving a VM that is running on host1 to host2)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Nova could probably update the port to point to a new host on live migration. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-right:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 0cm;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"> 2. I am not sure it would be wise to move this information to Quantum. What you have escibed may work for Quantum in OpenStack but Quantum in oVirt may behave differently. The API
should be as generic as possible.<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I agree that we want to be careful about this. Quantum should be designed such that it can work well with Nova, but I don't think the core API should be nova-specific. The core
Quantum API will also be used to connect other OpenStack services that need to plug into networks (e.g., load-balancer as a service...) as well as other compute stacks all together (e.g., oVirt, as mentioned by garyk). <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-right:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 0cm;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><o:p> </o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Verdana","sans-serif"">4. plugin agent on compute_node: create tap device and attach it to bridge, set vlan and so on, return</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p>I'm worried that this is not sufficiently generic. In several cases, it is the compute platform that needs to create the device that represents the vNIC. My guess is that this model that you describe would primarily work for libvirt type=ethernet, I believe,
and that model has a several limitations. Other approaches that are better integrated with libvirt have libvirt create and attach the device based on libvirt XML (checkout out libvirt <interface> elements that have type=bridge or type=direct). There are
also vif-drivers for other platforms like XenServer that definitely don't go create tap devices. <o:p></o:p></p>
<p>I don't think this is sufficiently generic. In several cases, it is the compute platform that needs to create the device that represents the vNIC. My guess is that this model that you describe would primarily work for libvirt type=ethernet, I believe,
and that model has a several limitations. Other approaches that are better integrated with libvirt have libvirt create and attach the device based on libvirt XML (checkout out libvirt <interface> elements that have type=bridge or type=direct). There are
also vif-drivers for other platforms like XenServer that definitely don't go create tap devices. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-right:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 0cm;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Verdana","sans-serif"">5. quantum -server return the network information to nova, and then nova create VM.<br>
<br>
This workflow differentiates at:<br>
1. tap device is not created by nova, it is created by plugin agent. It will help us to use one unified vif-driver on the nova side for quantum.</span><o:p></o:p></p>
</blockquote>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p>For the same reasons I mentioned above, I believe the complexity of several vif-drivers in nova, while undesirable, is actually difficult to avoid. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-right:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 0cm;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Verdana","sans-serif""><br>
For notification feature, I hope keep it for metering's purpose.</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I do not think that we should mix the features. The metering is a feature that I think is used for billing. They may use the same infrastructure but I do not think that we may need
different approaches for both.<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">There are many things that will need to trigger off basic Quantum events (port creation/update/delete, floating ip allocation, etc.). Even though there will ultimately be different
type of consumers (plugin agents, services like DHCP/DNS, metering, troubleshooting/logging, etc.) I'm hoping we can build a solid base notification mechanism that can be leveraged by many/all of them. If there are conflicting goals for different, perhaps
we cannot, but I think we should first discuss what those conflicting goals, as they will inform our technical design. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Dan<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-right:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 0cm;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="font-family:"Verdana","sans-serif""><br>
Thanks<br>
Yong Sheng Gong</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">--
<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
Dan Wendlandt <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</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>
<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">-- <br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
Dan Wendlandt <o:p></o:p></p>
<div>
<p class="MsoNormal">Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><o:p></o:p></p>
<div>
<p class="MsoNormal">twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>