Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes for mac2iface tests with esoteric ifaces #411

Merged

Conversation

ogayot
Copy link
Contributor

@ogayot ogayot commented Dec 5, 2023

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.

ip link add type gre
ip -j addr show dev gre0 | jq '.[]["address"]'
> "0.0.0.0"

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.

ip link add link eth0 name eth0.222 type vlan id 222
ip -j addr show dev eth0 | jq '.[]["address"]'
> "00:16:3e:36:b5:0e"
ip -j addr show dev eth0.222 | jq '.[]["address"]'
> "00:16:3e:36:b5:0e"

Thank you,
Olivier

@codecov-commenter
Copy link

codecov-commenter commented Dec 5, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (db9d90b) 58.08% compared to head (95346c1) 58.08%.
Report is 2 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #411   +/-   ##
=======================================
  Coverage   58.08%   58.08%           
=======================================
  Files          16       16           
  Lines        2627     2627           
=======================================
  Hits         1526     1526           
  Misses       1101     1101           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@ogayot ogayot changed the title Test mac2iface esoteric ifaces Fixes for mac2iface tests with esoteric ifaces Dec 5, 2023
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. gre interfaces do not store a MAC address in the "address"
field:

 $ ip link add type gre
 $ ip -j addr show dev gre0 | jq '.[]["address"]'
    "0.0.0.0"

We now ensure that the test-suite calls mac2iface with only valid MAC
addresses. We also skip all the 00:00:00:00:00:00 addresses because they
are invalid and can be visible on multiple interfaces (not just the
loopback interface).

Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
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,
but for now we will just skip the interfaces that have a duplicate MAC
address.

 $ ip link add link eth0 name eth0.222 type vlan id 222
 $ ip -j addr show dev eth0 | jq '.[]["address"]'
    "00:16:3e:36:b5:0e"
 $ ip -j addr show dev eth0.222 | jq '.[]["address"]'
    "00:16:3e:36:b5:0e"

Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
@ogayot ogayot force-pushed the test-mac2iface-esoteric-ifaces branch from 148e081 to 95346c1 Compare December 5, 2023 21:24
@martin-belanger
Copy link
Collaborator

Thanks for the fix.

I need to revisit this at some point. I could have used different Python libraries (psutil, netifaces, or get-nic) to retrieve the interface information, but wanted to limit the number of dependencies (i.e. I was encouraged by other distros to limit the number of dependencies). That's how I ended up writing my own library (iputil.py). But now, with the issues you're finding, I'm wondering if that was the right choice. Maybe I should look into a standard Python library even if that adds more dependencies.

@martin-belanger martin-belanger merged commit 2336eab into linux-nvme:main Dec 6, 2023
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants