frr
frr copied to clipboard
mgmt_oper::test_oper.py has a sleep that is causing problems
Description
The test_oper.py( and test_scale.py ) both have sleep(2) in the code. This is causing failures in the CI because of this:
r1 = tgen.gears["r1"].net
check_kernel_32(r1, "11.11.11.11", 1, "")
check_kernel_32(r1, "12.12.12.12", 1, "")
check_kernel_32(r1, "13.13.13.13", 1, "red")
check_kernel_32(r1, "14.14.14.14", 1, "red")
time.sleep(2)
> do_oper_test(tgen, query_results)
do_oper_test has absolutely no way to repeat the test for a bit of time until it succeeds(or fails ) and as such we have the test failing because internal-status is 8 on a ipv6 route instead of 16 that is expected
Expected:
"prefix": "2003:333::1/128",
"route-entry": [
{
"protocol": "local",
"distance": 0,
"metric": 0,
"selected": [
null
],
"installed": [
null
],
"internal-flags": 8,
"internal-status": 16,
"uptime": "rubout",
"nexthop-group": {
"id": "rubout",
"nexthop": [
{
"nh-type": "ifindex",
"vrf": "rubout",
"gateway": "",
"interface": "r1-eth2",
"active": [
null
],
"fib": [
null
]
}
]
}
}
]
Got:
{
"prefix": "2003:333::1/128",
"route-entry": [
{
"protocol": "local",
"distance": 0,
"metric": 0,
"selected": [
null
],
"queued": [
null
],
"internal-flags": 8,
"internal-status": 8,
"uptime": "rubout",
"nexthop-group": {
"id": "rubout",
"nexthop": [
{
"nh-type": "ifindex",
"vrf": "rubout",
"gateway": "",
"interface": "r1-eth2",
"active": [
null
],
"fib": [
null
]
}
]
}
}
]
},
The 2003:33::1/128 address is programmed from the frr.conf file:
interface r1-eth2 vrf red ip address 3.3.3.1/24 ipv6 address 2003:333::1/64 exit
And queued is an entirely possible state to be in on startup under heavy system loads after 2 seconds. The test MUST have a way to wait till the desired state has been reached before deciding failure. Any test that straight up uses sleep will fail eventually in the cli and must NEVER be used.
Version
master
How to reproduce
put system under heavy load run the test
Expected behavior
described already
Actual behavior
described already
Additional context
No response
Checklist
- [X] I have searched the open issues for this bug.
- [X] I have not included sensitive information in this report.
To clarify the difference is in the status where expected is 16 and got is 8. 16 = installed, 8 = queued.