I introduced a change [0] that passes the CI gate, but it does so, because it it not actually tested by the CI. ;P
1. For it to be tested properly, I need to reduce the number of cpu's exposed to vpp, and that requires running with elevated privileges [CAP_SYS_NICE] from what I can tell. We discussed at the community meeting the sentiment that test shouldn't require elevated privileges to run. Can anyone provide some guidance on the best way you would like to proceed? 2. The test framework doesn't actually catch the root issue (and consequently needs to wait to timeout...). Once we drop support for python2 compatibility post 20.01, I'd like to have the tests listen to the log streams and act accordingly. But as I think about this, it would be helpful to understand the decisions behind a developer's use of perror vs clib_warning vs local loggers. Are there any gotchas I need to be aware of? I think it would be great addition to be able to test the way a non-developer would troubleshoot. 3. My current change fixes the issue when running the test outside of the custom test runner. I would like to hear any objections before I start moving the "magic" that goes on in that file into the test case. I *strongly* believe that the tests need to run consistently, whether run from 'make test', or from the test shell, or any other standard tooling. Paul [0] https://gerrit.fd.io/r/c/vpp/+/23555
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14642): https://lists.fd.io/g/vpp-dev/message/14642 Mute This Topic: https://lists.fd.io/mt/60950403/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-