[Rdo-list] Compute Node without firewall (iptables) and Linux bridge

Mon Nov 10 10:52:48 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hey,

I've looked closer into the issue. Indeed, neutron does not send
proper VIF details flags to disable hybrid bridging on nova side. The
issue was fixed with the following patch in master:

- - https://review.openstack.org/#/c/104240/

I've requested a backport for the patch for Icehouse and Juno:

- - https://review.openstack.org/133421 (Icehouse)
- - https://review.openstack.org/132759 (Juno)

We'll need to wait for the patch to be merged in corresponding
branches and be released to reach RDO repos though. So if you're keen
to get the functionality ASAP, you can apply the patch to your setup
in the meantime.

Cheers,
/Ihar

On 30/10/14 13:32, Ihar Hrachyshka wrote:
> Do you use monolithic OVS plugin or ML2 mechanism? If the latter,
> then the file is not involved, and you should instead try to change
> the value in:
> 
> /usr/lib/python2.6/site-packages/neutron/plugins/ml2/drivers/mech_openvswitch.py
>
>  That said, removal of .py file is not enough to make sure it's
> not involved since .pyc file is still there and is used when there
> is no .py counterpart.
> 
> On 30/10/14 11:56, Chris wrote:
>> I just found out that the file in the compute node: 
>> /usr/lib/python2.6/site-packages/neutron/plugins/openvswitch/ovs_neutron_plu
>
>> 
> 
> gin.py
>> where I edit the portbindings.OVS_HYBRID_PLUG doesn't has any 
>> effect. I even can delete the whole file, the bridge is still
>> being created and everything works normal.
> 
>> Where I can edit the code to prevent the bridge creation?
> 
>> Cheers Chris
> 
>> -----Original Message----- From: Chris
>> [mailto:contact at progbau.de] Sent: Thursday, October 30, 2014
>> 01:28 To: 'Ihar Hrachyshka'; 'rdo-list at redhat.com' Subject: RE:
>> [Rdo-list] Compute Node without firewall (iptables) and Linux
>> bridge
> 
>> What do you mean with re-plugged? During my testing I always
>> delete and create new Instances and every time the Linux
>> bridge+interfaces gets deleted and created as well.
> 
>> Cheers Chris
> 
>> -----Original Message----- From: Ihar Hrachyshka 
>> [mailto:ihrachys at redhat.com] Sent: Thursday, October 30, 2014 
>> 00:04 To: Chris; rdo-list at redhat.com Subject: Re: [Rdo-list] 
>> Compute Node without firewall (iptables) and Linux bridge
> 
>> Have you replugged your instances? VIF objects are persisted in
>> db, I guess with flags including the one that control whether a
>> bridge should be created.
> 
>> Do you still see those bridges created for new instances?
> 
>> /Ihar
> 
>> On 29/10/14 11:26, Chris wrote:
>>> Hello,
> 
>>> 1) we just don't need it, we are using the provider network
>>> which includes hardware firewalls. 2) We have huge performance 
>>> problems regarding TCP_CRR / TCP_RR. The OpenStack VMs can
>>> deal just half of TCP connections per second compared to our
>>> bare metal installations. Throughput (10Gbit NIC) is fine
>>> though. Specs VMs and bare metal are of course equal (RAM,
>>> Cores, etc.)
> 
>>> Did a lot of testing regarding the performance issues, it
>>> happens "after" the both (br-int/br-ex) openvswitches. Upgraded
>>> ovs to version 2.3 just fyi.
> 
>>> Cheers Chris
> 
> 
>>> -----Original Message----- From: rdo-list-bounces at redhat.com 
>>> [mailto:rdo-list-bounces at redhat.com] On Behalf Of Ihar 
>>> Hrachyshka Sent: Wednesday, October 29, 2014 16:51 To: 
>>> rdo-list at redhat.com Subject: Re: [Rdo-list] Compute Node
>>> without firewall (iptables) and Linux bridge
> 
>>> On 29/10/14 09:33, Chris wrote:
>>>> Hello
> 
> 
> 
>>>> I?m looking for a way to disable any firewall feature in one
>>>> of our compute nodes and prevent the creation of the Linux
>>>> bridge in the data path inside of this compute node.
> 
>>> Can you elaborate on reasons to disable it? Of course it sounds
>>> a bit not optimal, but do you have any performance concerns
>>> that you try to address in this way?
> 
> 
>>>> We using the RDO Icehouse release.
> 
> 
> 
>>>> Here is the configuration in the compute node:
> 
>>>> #/etc/neutron/plugin.ini
> 
>>>> [securitygroup]
> 
>>>> #firewall_driver = 
>>>> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
>
>>>>  firewall_driver = neutron.agent.firewall.NoopFirewall
> 
>>>> # enable_security_group = True
> 
>>>> enable_security_group = False
> 
> 
> 
>>>> #/etc/nova/nova.conf
> 
>>>> firewall_driver = nova.virt.firewall.NoopFirewallDriver
> 
>>>> #security_group_api = neutron
> 
> 
> 
>>>> #/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini
> 
>>>> [securitygroup]
> 
>>>> firewall_driver = neutron.agent.firewall.NoopFirewallDriver
> 
>>>> enable_security_group = False
> 
> 
> 
>>>> The firewall seems to be disabled but the bridge and the 
>>>> interfaces are being still created.
> 
>>>> I found an older post about it: 
>>>> http://lists.openstack.org/pipermail/openstack/2014-May/007079.html
>
>>>>  But changing ?portbindings.OVS_HYBRID_PLUG" from a
>>>> hard-coded "True" to "False" didn?t change anything.
> 
> 
> 
>>>> Please advise!
> 
> 
> 
>>>> Cheers
> 
>>>> Chris
> 
> 
> 
> 
> 
>>>> _______________________________________________ Rdo-list 
>>>> mailing list Rdo-list at redhat.com 
>>>> https://www.redhat.com/mailman/listinfo/rdo-list
> 
> 
>>> _______________________________________________ Rdo-list
>>> mailing list Rdo-list at redhat.com 
>>> https://www.redhat.com/mailman/listinfo/rdo-list
> 
> 
> 
> 
> 
> _______________________________________________ Rdo-list mailing
> list Rdo-list at redhat.com 
> https://www.redhat.com/mailman/listinfo/rdo-list
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUYJkAAAoJEC5aWaUY1u57WZkIAII4LUJWK1dMh1BCM+fnZrJl
wKsNXNs7kgIT4rmStz2UsNo6m+nwnwT+OM36Jigi4N7XZEDLMOvujx27Efd3o6M7
F1Tl3Ld/To4te0Ayvd1CF+xV6jW6u/NegSrPSeT7edosi8cBeFlOdh3F5NN6lyJe
c6LDspyCh8thX71bSlswMK4uHMlX4N856197r3/tuWpDPcRRy9g9n9+wF0avV3pv
j8sf2zZupyR54xJbNdjAbOp/qwBmAEeFG+dapWYg5IvMcfH0g9eatbfGRegEb2XU
F5AA0q/yve36FCG5FSZFVZLApwpIp5i4u2Dl7pygSUT5UdY9rsxVsHQhs8DlSkw=
=DpTW
-----END PGP SIGNATURE-----