Properly check for ipset ranges, fixes #26453

[bobrik]

This add support for idempotent runs of ipset.present state if ranges are used as entries. IP1-IP2 and IP/MASK variants are supported.

Not sure if the branch is correct, though. I'd like to see this in the next release (2015.8.0).

[jfindlay]

Nice, thanks, @bobrik.

[jfindlay]

@bobrik, there are some lint errors (look for proposed fix:). I think we should also add some documentation and examples to the check function that illustrates the new range and subnet checking support. Otherwise looks great.

[bobrik]

PR is updated and linter is happy now.

[jfindlay]

Thanks @bobrik.

[bobrik]

@jfindlay any chance to see this in 2015.8?

[jfindlay]

@bobrik, I think we can backport it, but we need to add documentation about the added range checking feature.

[garethgreenaway]

@bobrik I'm curious what version of ipset you tested this with as I'm seeing some different results with your change.

[bobrik]

@garethgreenaway my change doesn't touch anything that calls ipset. ipset.check happens entirely in python. I'm using ipset v6.23 on jessie.

How different are your results?

[garethgreenaway]

ipset.check doesn't call the ipset binary but the call to _find_set_members within ipset.check does. The major different I'm seeing is related to the IP range. With ipset v6.25.1 when an ip range is specified the result is a network (or series of networks) with prefix lengths, eg. 192.168.1.0/24, not a list of IPs. So ipset.check never matches following the initial insertion of the ipset rules. I'll spin up a jessie VM and see if I can see the difference. Thanks!

[bobrik]

@garethgreenaway it can depend on ipset type, I use hash:ip and when you insert range you always get list of IPs, not networks, back.