<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
Please see my comments below.<br>
Thanks<br>
Gary<br>
<br>
On 07/20/2012 03:07 AM, Yong Sheng Gong wrote:
<blockquote
cite="mid:OF656C1745.ADBFFE1B-ON48257A41.0000B1B6-48257A41.0000B1BE@cn.ibm.com"
type="cite"><font face="Default Sans
Serif,Verdana,Arial,Helvetica,sans-serif" size="2"> <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>
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>
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>
3. The device ID should be set only one the VM has been deployed
on the Host. It may not be know at the time of the port creation.<br>
4. A number of agents need to be updated - quantum agent for
networking, dhcp agent for IP allocation, firewall agent for
security policies, load balancing agent for ssl offloading (oops I
am starting to slide into the grizzlie features for G4), ...<br>
<br>
<blockquote
cite="mid:OF656C1745.ADBFFE1B-ON48257A41.0000B1B6-48257A41.0000B1BE@cn.ibm.com"
type="cite"><font face="Default Sans
Serif,Verdana,Arial,Helvetica,sans-serif" size="2"><span>3.quantum-server
plugin: in addition to the port operation itself, rpc to
plugin agent on the specified compute_host to create tap
device<br>
</span></font></blockquote>
<br>
In the code that I have written the agent notifies the plugin that a
device has been created. The plugin may or may not store this
information.<br>
<blockquote
cite="mid:OF656C1745.ADBFFE1B-ON48257A41.0000B1B6-48257A41.0000B1BE@cn.ibm.com"
type="cite"><font face="Default Sans
Serif,Verdana,Arial,Helvetica,sans-serif" size="2"><span>4.
plugin agent on compute_node: create tap device and attach it
to bridge, set vlan and so on, return<br>
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>
<br>
Each agent has different requirements for the creation of the tap
devices. <br>
<blockquote
cite="mid:OF656C1745.ADBFFE1B-ON48257A41.0000B1B6-48257A41.0000B1BE@cn.ibm.com"
type="cite"><font face="Default Sans
Serif,Verdana,Arial,Helvetica,sans-serif" size="2"><span>2. tap
device is created and connected by agent, so it will remove
the latency where VM is started by the tap device is not
connected well.<br>
<br>
<br>
for deletion:<br>
we can use the same way, or polling in agent<br>
<br>
For notification feature, I hope keep it for metering's
purpose.<br>
</span></font></blockquote>
<br>
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>
<blockquote
cite="mid:OF656C1745.ADBFFE1B-ON48257A41.0000B1B6-48257A41.0000B1BE@cn.ibm.com"
type="cite"><font face="Default Sans
Serif,Verdana,Arial,Helvetica,sans-serif" size="2"><span><br>
Thanks<br>
Yong Sheng Gong<br>
<br>
</span><br>
</font>
</blockquote>
<br>
</body>
</html>