[ovirt-devel] [VDSM] CI failure - testEnablePromisc (ipwrapperTests.TestDrvinfo)

Dan Kenigsberg danken at redhat.com
Wed Dec 9 12:44:38 UTC 2015


On Mon, Dec 07, 2015 at 12:15:37AM +0200, Nir Soffer wrote:
> Hi all,
> 
> This is not the first time this test fails, but it is a rare failure.
> 
> Anyone has a clue why it fails?
> 
> According the captured log, all the ip runs are successful.
> 
> Can it be an issue on specific slave?
> 
> 21:25:25 ======================================================================
> 21:25:25 FAIL: testEnablePromisc (ipwrapperTests.TestDrvinfo)
> 21:25:25 ----------------------------------------------------------------------
> 21:25:25 Traceback (most recent call last):
> 21:25:25   File
> "/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/tests/ipwrapperTests.py",
> line 130, in testEnablePromisc
> 21:25:25     "Could not enable promiscuous mode.")
> 21:25:25 AssertionError: Could not enable promiscuous mode.
> 21:25:25 -------------------- >> begin captured logging << --------------------
> 21:25:25 root: DEBUG: /usr/bin/taskset --cpu-list 0-1 /usr/sbin/brctl
> show (cwd None)
> 21:25:25 root: DEBUG: SUCCESS: <err> = ''; <rc> = 0
> 21:25:25 root: DEBUG: /usr/bin/taskset --cpu-list 0-1 /sbin/ip link
> add name vdsm-ooqBPb type bridge (cwd None)
> 21:25:25 root: DEBUG: SUCCESS: <err> = ''; <rc> = 0
> 21:25:25 root: DEBUG: /usr/bin/taskset --cpu-list 0-1 /sbin/ip link
> set dev vdsm-ooqBPb up (cwd None)
> 21:25:25 root: DEBUG: SUCCESS: <err> = ''; <rc> = 0
> 21:25:25 root: DEBUG: /usr/bin/taskset --cpu-list 0-1 /sbin/ip link
> set dev vdsm-ooqBPb promisc on (cwd None)
> 21:25:25 root: DEBUG: SUCCESS: <err> = ''; <rc> = 0
> 21:25:25 --------------------- >> end captured logging << ---------------------
> 
> See http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/1101/console

Edy, can you check if this is a case of slowliness?

    /sbin/ip link set dev vdsm-ooqBPb promisc on

may be async, returning before the in-kernel state has changed.

Until the issue is resolved, we should mark the test as broken,
specifying as much information we can on @brokentest().



More information about the Devel mailing list