Skip to content

Factory config test bpi r3 - #1718

Merged
mattiaswal merged 2 commits into
mainfrom
factory-on-bpi
Oct 23, 2026
Merged

mattiaswal merged 2 commits into
mainfrom
factory-on-bpi

Conversation

@mattiaswal

Copy link
Copy Markdown
Contributor

BPI has a lan bridge causing the factory-config test to fail, since it may connect to some other dut through the bridge.

This adds a possible layer that it need to connect to a unit with the correct hostname, you probably never want to use it outside factory config test.

Description

Checklist

Tick relevant boxes, this PR is-a or has-a:

  • Bugfix
    • Regression tests
    • ChangeLog updates (for next release)
  • Feature
    • YANG model change => revision updated?
    • Regression tests added?
    • ChangeLog updates (for next release)
    • Documentation added?
  • Test changes
    • Checked in changed Readme.adoc (make test-spec)
    • Added new test to group Readme.adoc and yaml file
  • Code style update (formatting, renaming)
  • Refactoring (please detail in commit messages)
  • Build related changes
  • Documentation content changes
    • ChangeLog updated (for major changes)
  • Other (please describe):

@mattiaswal
mattiaswal requested a review from wkz October 21, 2026 05:55
@mattiaswal

Copy link
Copy Markdown
Contributor Author

I feel like the logic about getting the hostname is a bit malplaced in infamy, another solution would be to have all logic in the test, and just have the llscan in infamy. What do you think is best? @wkz

@mattiaswal
mattiaswal marked this pull request as draft October 21, 2026 06:23

@wkz wkz left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed AFK, I think a better approach might be:

  1. Make ll6ping() return all neighbors - like it should always have done
  2. Refine the attachment logic to pick the management IP from the physical topology when that is defined, otherwise fall back to a ping.
  3. Require that the ping sees only one neighbor - if multiple peers are on the link, and the user has not specified which one to use, then we should fail with a message saying so. That should help the next person setting up a test system with devices with bridging in their factory configs.

@mattiaswal
mattiaswal requested a review from wkz October 22, 2026 08:15
@mattiaswal
mattiaswal marked this pull request as ready for review October 22, 2026 08:15
@mattiaswal
mattiaswal force-pushed the factory-on-bpi branch 3 times, most recently from 4112c85 to bb452d4 Compare October 23, 2026 07:40

@wkz wkz left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We got there in the end! 😄

Letting the (quite unique) test handle this complexity feels right! 👍

A test may need a DUT outside its logical topology, and the mapping
lookup raised KeyError for any name not in it.
A factory config that bridges the mgmt port with links to other DUTs
makes all of them answer the host's IPv6LL probe, so the test attaches
to the wrong box.  Disabling every non-management port on every DUT in
the physical topology leaves only the target on that port.
@mattiaswal mattiaswal added the ci:skip Skip CI for this PR, started jobs are stopped. label Oct 23, 2026
@mattiaswal
mattiaswal merged commit 43e3b5d into main Oct 23, 2026
1 of 2 checks passed
@mattiaswal
mattiaswal deleted the factory-on-bpi branch October 23, 2026 09:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ci:skip Skip CI for this PR, started jobs are stopped.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants