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 -- Mailing list: https://launchpad.net/~netstack Post to : [email protected] Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
