<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>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>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>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><br>Thanks<br>Yong Sheng Gong<br><br></span><br></font>