I probably won't have time to look at this for a while, but I don't have any magic insights. I would just start adding in a bunch of logging of the values before they are shipped off to iptables to figure out if there are duplicate entries and such.
Vish On Dec 13, 2012, at 1:52 AM, Édouard Thuleau <thul...@gmail.com> wrote: > 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
