topology: allow peering links between core ASes #4605
Conversation
|
This change is |
oncilla
changed the title
There was a problem hiding this comment.
Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @FR4NK-W and @jiceatscion)
a discussion (no related file):
Could we get a test that ensures it actually works end to end too?
We need to ensure beaconing actually includes these links, and that the path combinator finds them.
There was a problem hiding this comment.
Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @FR4NK-W and @oncilla)
a discussion (no related file):
Previously, oncilla (Dominik Roos) wrote…
Could we get a test that ensures it actually works end to end too?
We need to ensure beaconing actually includes these links, and that the path combinator finds them.
Fair request. While I do that, would you happen to have an idea why the end-2-end tests have become so flaky. It's getting near impossible to get them to pass. What I've found so far is that right after "awaitconnectivity" it still takes up to 20 seconds for all the up segments to get turned around and registered as down segments (something that awaitconnectivity does not check"). I still do not know what's taking so long. I'm adding a 20s sleep at the end of awaitconnectivity in the mean-time so we can continue making PRs.
There was a problem hiding this comment.
Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @FR4NK-W and @jiceatscion)
a discussion (no related file):
Previously, jiceatscion wrote…
Fair request. While I do that, would you happen to have an idea why the end-2-end tests have become so flaky. It's getting near impossible to get them to pass. What I've found so far is that right after "awaitconnectivity" it still takes up to 20 seconds for all the up segments to get turned around and registered as down segments (something that awaitconnectivity does not check"). I still do not know what's taking so long. I'm adding a 20s sleep at the end of awaitconnectivity in the mean-time so we can continue making PRs.
I do not know, what you could try to do is to look at the distributed traces.
There should be a jaeger instance running, and all RPCs + control internal processes are tracked there.
There was a problem hiding this comment.
Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @FR4NK-W and @oncilla)
a discussion (no related file):
Previously, oncilla (Dominik Roos) wrote…
I do not know, what you could try to do is to look at the distributed traces.
There should be a jaeger instance running, and all RPCs + control internal processes are tracked there.
Yup...I's trying not to get to that :-)
There was a problem hiding this comment.
Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @FR4NK-W and @jiceatscion)
a discussion (no related file):
Previously, jiceatscion wrote…
Yup...I's trying not to get to that :-)
It is the first place I reach for if things don't work. Really powerful tool.
The sleep 10 at the end is a crutch until we figure out why down-segments take so long to get registered.
That is, until we figure out why they've become flaky.
There was a problem hiding this comment.
Reviewable status: 0 of 9 files reviewed, 1 unresolved discussion (waiting on @FR4NK-W and @oncilla)
a discussion (no related file):
Previously, oncilla (Dominik Roos) wrote…
It is the first place I reach for if things don't work. Really powerful tool.
Back to the main topic. Your suspicion was right. Adding a beaconning test revealed that core ASes assume they don't have peering links to include. That's now fixed. Plus the tests. The combinator had no issue.
There was a problem hiding this comment.
Reviewed 1 of 1 files at r1, 8 of 8 files at r2, all commit messages.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on @FR4NK-W)
Fixes #4484