Rework error handling logic in neighbor discovery #35144
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This comment was marked as outdated.
This comment was marked as outdated.
ovidiutirla
requested changes
Oct 2, 2024
cb1041f to
324355b
Compare
This comment was marked as outdated.
This comment was marked as outdated.
324355b to
624e2d8
Compare
|
/test |
gentoo-root
approved these changes
Oct 2, 2024
ovidiutirla
approved these changes
Oct 2, 2024
Add AllMatch function that returns true if the predicate evaluates to true for each element in the slice. Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com>
When a new node is discovered, in case of a multi-devices environment, we loop over each neighbor discovery link to found the next hop IP for the given node. For each link, if a next hop is found, it is inserted in the related neighNextHopByNode4 map. In this setup, it is possible that a node is reachable only by a subset of the neighbor discovery links. This case should not be considered an error, as long as the node is reachable by at least one link. Therefore, the errors handling logic is changed to propagate an error only when it is not possible to find a next hop for any link. This also reduces the amount of memory used for joining all the strings related to the false error condition described above, besides reducing the amount of useless retry runs of the node-neighbor-link-updater controller. Fixes: cilium#34020 Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com>
624e2d8 to
192a35e
Compare
|
/test |
|
Reviews are in and all required tests are green, marking ready to merge |
|
👋 is this worth backporting? |
@julianwiedmann I think it should be, yes, as evidenced by #35926. I can submit a PR if needed (both commits apply cleanly to |
Yep, being a bug it should be backported.
Np, I'm gonna take care of that, thanks anyway! 🤝 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
When a new node is discovered, in case of a multi-devices environment, we loop over each neighbor discovery link to found the next hop IP for the given node. For each link, if a next hop is found, it is inserted in the related neighNextHopByNode4 map.
In this setup, it is possible that a node is reachable only by a subset of the neighbor discovery links. This case should not be considered an error, as long as the node is reachable by at least one link. Therefore, the errors handling logic is changed to propagate an error only when it is not possible to find a next hop for any link.
This also reduces the amount of memory used for joining all the strings related to the false error condition described above, besides reducing the amount of useless retry runs of the node-neighbor-link-updater controller.
Related: #34020