[libvirt] [PATCH 00/26] Rewrite firewall code to use formal API

[Stefan Berger]

On 04/15/2014 10:06 AM, Daniel P. Berrange wrote:
> On Tue, Apr 15, 2014 at 10:04:01AM -0400, Stefan Berger wrote:
>> On 04/15/2014 07:42 AM, Daniel P. Berrange wrote:
>>> On Tue, Apr 15, 2014 at 07:40:41AM -0400, Stefan Berger wrote:
>>>> On 04/15/2014 04:29 AM, Daniel P. Berrange wrote:
>>>>> On Mon, Apr 14, 2014 at 04:47:50PM -0400, Stefan Berger wrote:
>>>>>> On 04/08/2014 11:37 AM, Daniel P. Berrange wrote:
>>>>>>> Currently we have three places which interact with the firewall
>>>>>>>
>>>>>>>    - util/virebtables - simple MAC filtering used by QEMU driver
>>>>>>>    - util/viriptables - used by network driver
>>>>>>>    - nwfilter - general purpose guest filtering
>>>>>> Oh my, so much work! -- Thanks
>>>>>>
>>>>>> I'll review as much as I can.
>>>>> Thanks, I appreciate any review you can do particularly of the big
>>>>> nwfilter patches, since you're main expert in that area.
>>>> Some of the patches are so involved that besides looking at them
>>>> I'll mostly have to rely on the TCK tests to see whether they still
>>>> pass. The TCK tests unfortunately also need updating due to recent
>>>> changes in the code (elimination of the source MAC tests in recent
>>>> patches) as well as different output by the ip6tables command
>>>> related to IPv6 addresses.
>>> The TCK tests shouldn't need updating. The current libvirt-tck GIT
>>> master nwfilter tests pass against libvirt GIT master, and also
>>> pass after this patch series is applied (at least on Fedora 20).
>> That's interesting. I am running this on Fedora 18. This patch here
>>
>> https://www.redhat.com/archives/libvir-list/2014-March/msg00660.html
>>
>> is necessary on Fedora 18, but not on Fedora 20 I assume. Probably
>> it was a temporary regression in iptables.
>>
>> Is this patch series incremental so that the TCK test suite should work
>> after each one of them? At least for me it passes up to patch 7/26
>> but then patch 8/26 starts causing ip6tables related problems.
> It was intended to be incremental, but I honestly haven't tested the
> TCK against the individual patches - only the end result.

I did some more tests now using iptables directly. From what I can see 
it is working as expected. There was a locking problem that I just sent 
a patch for. So from my perspective these patches can go in with the 
modifications applied to 16/26.

Regards,
    Stefan