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

tests: Do not use peerUptime as a measure of if a clear worked #4758

Merged
merged 1 commit into from
Aug 1, 2019

Conversation

donaldsharp
Copy link
Member

The peerUptime data received from a show bgp ipv4 uni summ json
gives you the time in seconds since the peer has come up.
The clear_bgp_and_verify function is checking the peerUptime
for before and after and if they are the same then the test
was declaring a clear failure.

The problem with this is of course that the tests can run fast
enough that the peerUptime is the same for before and after the clear.

Modify the test case to use peerUptimeEstablishedEpoch.
This value is the seconds since the epoch since the establishment
of the peer. This will allow us to know that a clear happened.

Signed-off-by: Donald Sharp sharpd@cumulusnetworks.com

The peerUptime data received from a `show bgp ipv4 uni summ json`
gives you the time in seconds since the peer has come up.
The clear_bgp_and_verify function is checking the peerUptime
for before and after and if they are the same then the test
was declaring a clear failure.

The problem with this is of course that the tests can run fast
enough that the peerUptime is the same for before and after the clear.

Modify the test case to use peerUptimeEstablishedEpoch.
This value is the seconds since the epoch since the establishment
of the peer.  This will allow us to know that a clear happened.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
@polychaeta polychaeta added the tests Topotests, make check, etc label Jul 31, 2019
@LabN-CI
Copy link
Collaborator

LabN-CI commented Jul 31, 2019

💚 Basic BGPD CI results: SUCCESS, 0 tests failed

Results table
_ _
Result SUCCESS git merge/4758 abdb6bc
Date 07/31/2019
Start 12:35:21
Finish 12:57:18
Run-Time 21:57
Total 1815
Pass 1815
Fail 0
Valgrind-Errors 0
Valgrind-Loss 0
Details vncregress-2019-07-31-12:35:21.txt
Log autoscript-2019-07-31-12:36:21.log.bz2
Memory 395 440 360

For details, please contact louberger

@NetDEF-CI
Copy link
Collaborator

Continuous Integration Result: SUCCESSFUL

Congratulations, this patch passed basic tests

Tested-by: NetDEF / OpenSourceRouting.org CI System

CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-8487/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

Warnings Generated during build:

Debian 10 amd64 build: Successful with additional warnings

Debian Package lintian failed for Debian 10 amd64 build:
(see full package build log at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-8487/artifact/DEB10BUILD/ErrorLog/log_lintian.txt)

W: frr source: changelog-should-mention-nmu

CLANG Static Analyzer Summary

  • Github Pull Request 4758, comparing to Git base SHA 2e6f2d6

No Changes in Static Analysis warnings compared to base

1 Static Analyzer issues remaining.

See details at
https://ci1.netdef.org/browse/FRR-FRRPULLREQ-8487/artifact/shared/static_analysis/index.html

@eqvinox eqvinox merged commit b21ea71 into FRRouting:master Aug 1, 2019
@donaldsharp donaldsharp deleted the test_epoch branch December 9, 2019 16:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tests Topotests, make check, etc
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants