Quick reply wrt to point 2. This is just the way I separate things, others may have different opinions:
- I believe perror is called after some syscall fails. Alternatively, clib_unix_error/clib_unix_warning maybe used for the same purpose - If by local loggers you mean the vlib log infra, that is not thread safe and is typically used from main thread when features are initialized or on some cli/api event. If you meant loggers that wrap clib_warning or ffprint, then those are probably meant for debugging from workers. It can be that the latter are not always on. - direct calls to clib_warning from workers are typically left in to report “unexpected” conditions, although the practice is not encouraged. Florin > On Nov 20, 2019, at 9:32 AM, Paul Vinciguerra <pvi...@vinciconsulting.com> > wrote: > > 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 > <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/675152 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [fcoras.li...@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14647): https://lists.fd.io/g/vpp-dev/message/14647 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] -=-=-=-=-=-=-=-=-=-=-=-
