Suspected regression caused by #1347

[Jc2k]

Was preparing to upgrade to 0.13.2 (Yay for CR!) but #1347 has me worried.

I actually have some interfaces (type=vlan) where I don't want the host itself to consume an IP (due to size of allocation but also because its needless attack surface area), but where I do use MetalLB to manage floating IP's that are on those interfaces. This works on the prior release, and has done for a couple of years. The interface has no ipv4 or ipv6 addresses:

$ ip a s external
11: external@bond1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 12:34:56:78:9a:bc brd ff:ff:ff:ff:ff:ff

But from the description on #1347, it will no longer work on 0.13.x?

And without #1490, there is no way to override this automatic filtering?

So as it stands, this feels like a regression.

[fedepaol]

Oh, makes sense and we didn't think about this use case.
I guess we could have this as a property of l2 advertisement, with the current behaviour being the default.
Would it make sense @Jc2k ?
cc @pperiyasamy

[fedepaol]

Or, let me have a look at the codebase and come up with the right solution.
In any case @Jc2k you are right, as it stands that use case wouldn't work anymore :/

[Jc2k]

If my understanding is right, #1490 would solve this because I could control exactly which interfaces were in use, and any automatic filtering would not apply.

In which case, as its a regression ideally we'd back out #1347 until #1490 landed. I'm not sure what ripple effects there might be with that approach though.

I'm not sure it makes sense to add a property for this case if #1490 will be enough, but if #1490 is still a while a way and reverting the regression is not possible, then it might be for the best...

[fedepaol]

Yep, we'll find a solution.
Let me think about it a bit and not to rush to any conclusion. Sorry about the regression

[fedepaol]

Filed #1516

[fedepaol]

Closing as #1516 is merged