Open Stack

Hi,
Please see my comments below.
Thanks
Gary

On 07/20/2012 03:07 AM, Yong Sheng Gong wrote:
>
> hi,
> I think the workflow can be this:
> 1. nova quantum api: allocate_for_instance(compute_host, device_id)
> 2.quantum-server: create_port(compute_host, device_id), we need to 
> extend port model to include compute_host

I think that this is problematic in a number of respects:
     1. not sure how this will work for live migration (that is moving a 
VM that is running on host1 to host2)
     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.
     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.
     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), ...

> 3.quantum-server plugin: in addition to the port operation itself, rpc 
> to plugin agent on the specified compute_host to create tap device

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.
> 4. plugin agent on compute_node: create tap device and attach it to 
> bridge, set vlan and so on, return
> 5. quantum -server return the network information to nova, and then 
> nova create VM.
>
> This workflow differentiates at:
> 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.

Each agent has different requirements for the creation of the tap devices.
> 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.
>
>
> for deletion:
> we can use the same way, or polling in agent
>
> For notification feature,  I hope keep it for metering's purpose.

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.
>
> Thanks
> Yong Sheng Gong
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120720/83a47a18/attachment.html>