WIP: use netlink instead of calling iproute2 commands

[gwenya]

See #1978

This is still WIP, the PR at this time is mainly for running the CI. Feedback is very welcome though, especially on the non-trivial TODOs.

[gwenya]

@stgraber we currently don't have any tests specifically for this package, if any of the functions are tested then only incidentally.
Unit tests don't really work since this interacts with the system and there's no point in mocking that.
I'm thinking maybe a test program that can run any of these functions via reflection, and then a test script that calls said program and uses iproute2 tools to check if it does things correctly.
And ideally I'd like to be able to run these tests locally without messing up my network setup, so in a VM maybe. I'm not sure if that fits into our current testing system somehow?
Some of these might not even be possible to test in the CI, for example vrf is a kernel module that may or may not be loaded.

[stgraber]

Yeah, it's not the kind of code that's particularly directly testable, it makes more sense to have it be indirectly tested through or normal system tests and the daily test runs we have on Jenkins too.

[gwenya]

Hmh can we generate coverage data from the existing tests to see if they hit all the code paths in this package?

[stgraber]

Hmm, not particularly easily as we typically run our tests across a LOT of incusd instances, so can't centrally keep track of everything that was hit. And some of the more complex bits (SR-IOV and the like) are tested externally, some manually, some automatically through Jenkins.

[gwenya]

Hmh I see
The tests already caught some bugs that I'm fixing now but without knowing if everything is tested it's hard having confidence in the end result

[stgraber]

@gwenya yeah, the best we can do is land this one early in the release to maximize the time we have for all our various tests to catch issues.

[gwenya]

@stgraber should I put these kinds of changes into their own commit or leave them together with the corresponding change in the ip package?

[stgraber]

it's fine to leave them with the change I think

[gwenya]

I am not confident about this ID being the number we want.

In the iproute2 code the vf is taken from IFLA_VF_MAC, and that's where the netlink library puts it when setting it, but this ID seems to be just the index in the list of vfs returned from the kernel.

I don't have any SR-IOV capable devices to try out if this is the same. If not then we might have to request a change on the netlink library to expose the correct value.

[stgraber]

You may want to request access to https://discuss.linuxcontainers.org/t/opening-up-the-linux-containers-lab-environment/22588

The lab has quite a few SR-IOV capable systems:

• lantea (dual-port ConnectX-4, single-port Intel 10Gbit)
• asuras (dual-port ConnectX-6)
• entak (dual-port ConnectX-6)
• velona (dual-port ConnectX-6)

[stgraber]

Of those at least lantea is known to be correctly configured at the firmware level as it does run SR-IOV daily tests for us.

[gwenya]

The vlan link type is blocked on vishvananda/netlink#1078, since the netlink library currently does not support setting the gvrp flag on vlan links.

The veth link type is semi-blocked on vishvananda/netlink#1079 since the netlink library currently does not support setting more than peer name and address on veth create, but we could probably work around that by adjusting the other settings after creating it.