openstack team mailing list archive

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

On Fri, Dec 09, 2011 at 09:02:09AM -0800, Dan Wendlandt wrote:
> Oh, definitely.  I really should have set "create a blueprint and target it as
> essex-3 as a place-holder".  We'll definitely need to talk through the design
> first (though we probably don't need to flood the entire OS community with such
> detailed discussions, so we can move it to the netstack list).  

Okay.


>     - window between port creation and port becoming usable.
>      Currently, there is a window that VM can't connect to the network.
> 
>      1. ovs port creation by nova-compute virt-driver
>      2. nova-compute call nova-network which calls quantum rest API
>      3. instance creation and guest VM starts.
>         the VM can't send/receive until OVS agent finds the port.
>      4. ovs agent polls on compute node, and make the port available. 
> 
> 
>      I'd like to fix the window. nova-network doesn't have informations enough.
>      So the possible options is
>      - have nova-compute call quantum API, or
>      - have nova-compute pass more information (maybe libvirt_vif_driver
>        specific) as rpc argument to nova-network
>      Maybe the first option would make the code simple, but it breaks the
>      boundary between compute and netowrk. So my preference is the second
>     option.
>      Or any other ideas?
> 
> 
> 
> I think the order above is incorrect.  If you look in nova/compute/manager.py's
> _run_instance() method, the allocate_network() call is called before _spawn(),
> which IIRC means that Quantum will be called and the port created + attached
> before the VM port is created on OVS or the VM is started.  So I don't think
> there's a fundamental ordering problem.  It may just be that the polling period
> in the OVS agent needs to be tuned down.  I've been thinking about splitting
> the logic that spots a port and putting it in a separate thread with a shorter
> polling interval, which may help.  Or it may be a bug that you're seeing :) 

The polling period is the window. Shortening the interval make the window
small, but never eliminates it. I'd like to make the agent work done before
staring instance.


>     > It also looks like you have some small nova changes, mostly around the
>     > QuantumManager + OVS vif-plugging.  I think some of them may not be
>     necessary
>     > after some work done by brad in essex-2 around integrating QuantumManager
>     with
>     > L3 + NAT (recently merged into trunk), but we can help figure that out as
>     well.
> 
>     The new firewall driver and network interface driver we introduced are
>     for demonstration making the point clear.
>     Nop firewall driver is introduced in order to show that the packet
>     filtering
>     is done by Ryu, not by iptables.
>     If iptables firewall driver is enabled, it doesn't harm, it's just
>     bypassed.
> 
> 
> Yeah, that made sense.  I was more talking about some of the tweaks you did to
> enable metadata + and general L3 forwarding in QuantumManager.  Brad had a
> blueprint on that part fo the code that went in a week or so ago.  

I see. I'll have a look at the blue print.

-- 
yamahata