Fixes for mac2iface tests with esoteric ifaces #411
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello,
I know I said I wouldn't be doing more tests on nvme-stas in the near future, but the CI failed in Ubuntu on runners that have
gre
network interfaces.. so sending you my findings :)There are two fixes to the test-suite in the PR. Well, one that I would call a proper fix and one which is more of a workaround..
Patch 1
mac2iface takes a MAC address as argument and returns the corresponding interface (if any). The mac2iface tests will however invoke mac2iface with invalid MAC addresses when esoteric network interfaces are present on the system. As an example,armhf autopkgtest runners in Ubuntu have gre interfaces configured so the test-suite fails.
We now ensure that the test-suite calls mac2iface with only valid MAC addresses. We also skip interfaces that have
00:00:00:00:00:00
since it is theoretically invalid and can be assigned to multiple type of interfaces.Patch 2 (more of a workaround)
Sometimes the same MAC address is assigned to more than one interface on the system (this is true for VLAN interfaces for instance). This confuses
mac2iface
, which returns only the first match.This scenario is possibly more of a nvme-stas bug than a test-suite bug. I am not sure how to fix it properly (should a mac2ifaceS function be provided?). So for now I chose to skip the test for interfaces that share the same MAC address.
Thank you,
Olivier