When trying to associate floating ip, when using nova network, it may fail with 

> BadRequest: Bad request
> Details: {'message': 'Error. Unable to associate floating ip', 'code': '400'}

Reason is that rootwrap call to ebtables failed.

> Command: sudo nova-rootwrap /etc/nova/rootwrap.conf ebtables -t nat -I PREROUTING --logical-in br100 -p ipv4 --ip-src 192.168.32.2 ! --ip-dst 192.168.32.0/22 -j redirect --redirect-target ACCEPT
> Exit code: 255
> Stdout: ''
> Stderr: "The kernel doesn't support a certain ebtables extension, consider recompiling your kernel or insmod the extension.\n" to caller

Same issue may actually happen with Icehouse on RHEL7:

> Command: sudo nova-rootwrap /etc/nova/rootwrap.conf ebtables -t nat -I PREROUTING --logical-in br100 -p ipv4 --ip-src 192.168.32.10 ! --ip-dst 192.168.32.0/22 -j redirect --redirect-target ACCEPT
> Exit code: 255
> Stdout: ''
> Stderr: "Unable to update the kernel. Two possible causes:\n1. Multiple ebtables programs were executing simultaneously.
>  The ebtables\n userspace tool doesn't by default support multiple ebtables programs running\n concurrently.
>  The ebtables option --concurrent or a tool like flock can be\n used to support concurrent scripts that update
>  the ebtables kernel tables.\n2. The kernel doesn't support a certain ebtables extension, consider\n
>  recompiling your kernel or insmod the extension.\n.\n"

So it's not related only to RHOS4/RHEL 6.5.

This happens randomly, and only like once per whole run of tempest (lot of servers created, floating ip's associated etc, so no issue with kernel support etc).

As the rootwrap calls seems to be synchronized with locks, there has to be something else running ebtables at the same time.
Possible offender could be libvirt/nwfilter, or similar out-of-openstack part.


Version-Release number of selected component (if applicable):
> ebtables.x86_64                    2.0.9-6.el6
> openstack-nova-network.noarch      2013.2.3-7.el6ost