Hi Vish, The code was merge to the master (https://github.com/openstack/nova/commit/d5b91dd39bd89eed98742cd02ea604a842a45447) yesterday.
But the bug with rule removal wasn't fix. I'll open a bug. But I try to investigate it and I don't find the problem. Could you help me ? Regards, Édouard. On Fri, Dec 7, 2012 at 6:45 PM, Édouard Thuleau <thul...@gmail.com> wrote: > The code doesn't make lot of change to the nova network manager code. It > modifies principally the linux_net driver code. > > And I don't think we can consider it like a new feature. I think it's more a > bug fix. > > In VLAN manger mode, if we plan to carry 4000 tenants in our cloud, we need > to use 4000 networks and, consequently, 4000 VLANs on all the datacenter > network. But the actual switch equipment cannot carry a trunk of 4000 VLAN > to all compute host (for example, Cisco Nexus 5500 can not enabled more than > 32000 logical interfaces[1] (= TRUNKS x VLANS + ACCESS_PORTS [2])). > If nova network tear down unused networks, it would be possible to plug a > mechanism on it to delete unused VLAN on the switch port. And we can > provisioning dynamically VLANs on switch ports and don't exceed the logical > interface limitation of networks equipments. > > [1]http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/configuration_limits/limits_513/nexus_5000_config_limits_513.html#wp344401 > [2] > http://jpmcauley.com/2011/06/23/vlan-port-instance-limitation-on-cisco-ucs/ > > > > On Mon, Dec 3, 2012 at 11:50 PM, Vishvananda Ishaya <vishvana...@gmail.com> > wrote: >> >> FYI, this patch is probably something bigger than we can merge. >> Nova-network is supposed to just be in maintenance mode and >> not getting big new features. Small features are ok, but this one changes >> a lot of lines. >> >> Not sure what is up with your rule removal. Perhaps there are multiple >> copies of the added rules so they aren't being deleted properly? In fact, >> that may be a bug. It looks like plug is called for each vm so we might end >> up with multiple copies of the isolation rules. >> >> Vish >> >> On Dec 3, 2012, at 6:34 AM, Édouard Thuleau <thul...@gmail.com> wrote: >> >> Hi Vish, >> >> I made a patch to implement that with the VLAN manager: >> https://review.openstack.org/#/c/17352/ >> >> I put a lock on methods '_setup_network_on_host' and >> '_teardown_network_on_host' of class 'VlanManager' and I reused (and >> renamed) the locks already defined in class 'LinuxBridgeInterfaceDriver' >> when a bridge or VLAN is created ('ensure_vlan' => 'lock_vlan' and >> 'unsure_bridge' => 'lock_bridge'). Do you think is enough to prevent any >> race condition ? >> >> I've got a bug. I create method '_remove_dnsmasq_accept_rules' to remove >> filter rules for DHCP server but when I call it, nothing is deleted. Could >> you help me to resolve that ? And I've got the same problem sometimes with >> method 'remove_isolate_dhcp_address'. The ebtables rules are correctly >> deleted but not for iptables rules. >> >> I didn't delete a network bridge if it handles VPN forward rules of the >> private network even if no VM use this gateway on the host. But if a network >> is deleted, nothing will tear down this gateway. >> I think I found another bug. If network host must handle the VPN forward >> rules for a private network and if we restart it, it should instantiate a >> gateway on this private network and add VPN forward rules even if no VM use >> this gateway on the host. But actually it doesn't do that. Perhaps, the >> method 'db.network_get_all_by_host' use in 'init-host' must return the >> network in this case ? >> >> I only implement this for the multi hosted networks with the VLAN manger. >> I think isn't useful to add this on the multi hosted network with the Flat >> DHCP manager because, in this mode, only one multi hosted network is created >> for all instances of all tenants. >> >> Regards, >> Édouard. >> >> On Wed, Nov 21, 2012 at 12:49 AM, Vishvananda Ishaya >> <vishvana...@gmail.com> wrote: >> > The only reason this is not done is that it makes the setup simpler. We >> > don't have to worry about potential races between setting up and tearing >> > down interfaces. It probably wouldn't be incredibly difficult to make a >> > patch that would remove them, but you will likely have to do some >> > creative >> > locking to make sure that you don't run into issues. >> > >> > Vish >> > >> > On Nov 20, 2012, at 9:25 AM, Édouard Thuleau <thul...@gmail.com> wrote: >> > >> >> Hi all, >> >> >> >> I use nova-network with VLAN manager. >> >> >> >> Why nova-network doesn't remove unused network interfaces on a host ? >> >> >> >> ie, if none VM on a host have a fixed IP attach to network X, the VLAN >> >> and bridge of this network still up and unused. And 'dnsmasq' process >> >> still listen and running. >> >> >> >> The number of unused network interfaces will grow over time. >> >> In the VLAN mode, this number could be 4000 x 2 unused interfaces and >> >> 4000 unused 'dnsmasq' processes (in worth case). >> >> >> >> Can it lead to decrease the kernel performance ? >> >> Is it a bug ? Or a voluntary implementation ? >> >> >> >> Regards, >> >> Édouard. >> >> >> >> _______________________________________________ >> >> Mailing list: https://launchpad.net/~openstack >> >> Post to : openstack@lists.launchpad.net >> >> Unsubscribe : https://launchpad.net/~openstack >> >> More help : https://help.launchpad.net/ListHelp >> > >> >> > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp