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]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to