[Openstack] [ANNOUNCE] Ryu OSS Network Operating System
yamahata at valinux.co.jp
Sat Dec 10 01:13:42 UTC 2011
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).
> - 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
> 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
> > 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
> > after some work done by brad in essex-2 around integrating QuantumManager
> > L3 + NAT (recently merged into trunk), but we can help figure that out as
> 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
> is done by Ryu, not by iptables.
> If iptables firewall driver is enabled, it doesn't harm, it's just
> 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.
More information about the Openstack