Hi Yong, Gary, <div><br></div><div>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. <br><br><div class="gmail_quote">
On Fri, Jul 20, 2012 at 12:30 AM, Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@redhat.com" target="_blank">gkotton@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<u></u>
<div bgcolor="#ffffff" text="#000000">
Hi,<br>
Please see my comments below.<br>
Thanks<br>
Gary<div><br>
<br>
On 07/20/2012 03:07 AM, Yong Sheng Gong wrote:
<blockquote type="cite"><font face="Default Sans
Serif,Verdana,Arial,Helvetica,sans-serif"> <span><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<br>
</span></font></blockquote>
<br></div>
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)<br></div></blockquote><div><br></div><div>Nova could probably update the port to point to a new host on live migration. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#ffffff" text="#000000">
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.<br><br></div></blockquote><div><br></div><div>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). </div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#ffffff" text="#000000"><div><br>
<blockquote type="cite"><font face="Default Sans
Serif,Verdana,Arial,Helvetica,sans-serif"><span>4.
plugin agent on compute_node: create tap device and attach it
to bridge, set vlan and so on, return<br></span></font></blockquote></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. </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. </p>
</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#ffffff" text="#000000"><div><blockquote type="cite"><font face="Default Sans
Serif,Verdana,Arial,Helvetica,sans-serif"><span>
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.<br></span></font></blockquote></div></div></blockquote><div><br></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. </p></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#ffffff" text="#000000"><div><blockquote type="cite"><font face="Default Sans
Serif,Verdana,Arial,Helvetica,sans-serif"><span>
<br>
For notification feature, I hope keep it for metering's
purpose.<br>
</span></font></blockquote>
<br></div>
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.<br></div></blockquote><div><br></div><div>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. </div>
<div><br></div><div>Thanks,</div><div><br></div><div>Dan</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#ffffff" text="#000000">
<blockquote type="cite"><font face="Default Sans
Serif,Verdana,Arial,Helvetica,sans-serif"><span><br>
Thanks<br>
Yong Sheng Gong<br>
<br>
</span><br>
</font>
</blockquote>
<br>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div><br>
</div>