openstack team mailing list archive

[Vishvananda Ishaya <vishvananda@xxxxxxxxx>]

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 <thuleau@xxxxxxxxx> 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 <thuleau@xxxxxxxxx> 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 <vishvananda@xxxxxxxxx>
>> 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 <thuleau@xxxxxxxxx> 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
>>> <vishvananda@xxxxxxxxx> 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 <thuleau@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>> 
>>> 
>>> 
>>