>> On 27 Dec 2019, at 22:48, Paul Vinciguerra <pvi...@vinciconsulting.com> >> wrote: > > Hi Andrew. > That was the test that caught my attention. I am of the opinion that s5ci > provides the behavior we expect.
I personally has requested the tap test in its time to be moved to extended tests, because of this. I presume the parties who made it appear in the standard tests will either chime into this discussion with their reasoning or will make it disappear :-) > I have a changeset that skips the test on s5ci instead of failing [0], but I > actually think that the proper test for the CI is a test where the test > fails, reporting insufficient permissions, since that is what an unprivileged > use would see. > > [0] https://gerrit.fd.io/r/c/vpp/+/24132 One can not decide if the lack of privileges is due to misconfiguration or due to intent, so there is no place for adaptivity and automagicness in this context. If we all agree that “make test” is supposed to succeed in the unprivileged environment then it should, end of story. With the exact same tests as in privileged environment. And then for the more demanding tests there should be some sort of “PRIVILEGED=yes make test” alternative that will invoke the tests that require additional privileges and fail if it doesn’t get them. With potentially more granular set of valued for “yes”. Testing is about determinism. —a >> On Fri, Dec 27, 2019 at 4:27 PM Andrew 👽 Yourtchenko <ayour...@gmail.com> >> wrote: >> I was under impression the “make test” was supposed to be passing when run >> under the regular user. That means that the recently added tap tests will >> make it fail: http://s5ci.myvpp.net/jobs/vpp-periodic-make-verify/ is only >> failures as of 12:25 UTC 24th December. >> >> So, what is the direction the community wants to go ? >> >> --a >> >>>> On 27 Dec 2019, at 17:22, Paul Vinciguerra <pvi...@vinciconsulting.com> >>>> wrote: >>> >>> I have been trying to figure out why I've been seeing different results >>> between the CI jobs and s5ci jobs. What I've discovered is that the CI >>> jobs are running as the root user in a fully privileged container, where >>> s5ci runs unprivileged. >>> I am aware that there has been a long-standing desire for tests to run as >>> an unprivileged user. Do we need to implement that constraint on the CI >>> tests? >>> From my tests in the CI [0]: >>> Sanity test case passed. >>> Running as root(0):root(0) >>> Capabilities: ['cap_chown', 'cap_dac_override', 'cap_dac_read_search', >>> 'cap_fowner', 'cap_fsetid', 'cap_kill', 'cap_setgid', 'cap_setuid', >>> 'cap_setpcap', 'cap_linux_immutable', 'cap_net_bind_service', >>> 'cap_net_broadcast', 'cap_net_admin', 'cap_net_raw', 'cap_ipc_lock', >>> 'cap_ipc_owner', 'cap_sys_module', 'cap_sys_rawio', 'cap_sys_chroot', >>> 'cap_sys_ptrace', 'cap_sys_pacct', 'cap_sys_admin', 'cap_sys_boot', >>> 'cap_sys_nice', 'cap_sys_resource', 'cap_sys_time', 'cap_sys_tty_config', >>> 'cap_mknod', 'cap_lease', 'cap_audit_write', 'cap_audit_control', >>> 'cap_setfcap', 'cap_mac_override', 'cap_mac_admin', 'cap_syslog', >>> 'cap_wake_alarm', 'cap_block_suspend', 'cap_audit_read+eip'] >>> OS reports 72 available cpu(s). Free shm: 1,023.9921875MB >>> Found enough resources to run tests with 4 cores >>> [0] >>> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1804/1331/console.log.gz >>> -=-=-=-=-=-=-=-=-=-=-=- >>> Links: You receive all messages sent to this group. >>> >>> View/Reply Online (#14981): https://lists.fd.io/g/vpp-dev/message/14981 >>> Mute This Topic: https://lists.fd.io/mt/69288694/675608 >>> Group Owner: vpp-dev+ow...@lists.fd.io >>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [ayour...@gmail.com] >>> -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14984): https://lists.fd.io/g/vpp-dev/message/14984 Mute This Topic: https://lists.fd.io/mt/69288694/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
