On Thu, May 31, 2018 at 10:34 AM Sandro Bonazzola <sbonazzo@redhat.com> wrote:
2018-05-16 17:12 GMT+02:00 Sandro Bonazzola <sbonazzo@redhat.com>:


2018-05-16 15:20 GMT+02:00 Nir Soffer <nsoffer@redhat.com>:
Ping


There's ongoing discussion about the real need of having travis testing. What do we test in travis that Jenkins is not testing already?

Travis give us several advantages:
- Generally more reliable, less tests marked broken on travis. I think the key is
  having fresh vm per build. I wish we had that in ovirt CI.
- Typically faster. Here is a random example:
  travis builds:
  - https://travis-ci.org/oVirt/vdsm/builds/386053193
  8 minutes
  gerrit builds:
  - https://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-x86_64/3571/
  - https://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/23748/
  20 minutes
- Need one url to refer to a build, instead of one url per platform
- Easier to setup and maintain - one yaml file, one dockerfile per platform
- We control the project configuration
- Easy to test project configuration - no need to merge to test a change
- Simpler, we run in a docker image, updated when the base image updates
  or manually by building from dockerfiles in vdsm source
- Easier to get contributions, lot of people know travis
- Anyone can run the tests in travis, no need for whitelists, just fork vdsm
  and enable travis builds in your private account
- Easy to test multiple python versions, even nighties
- Travis errors never fail builds, and sometimes even restart a build
   it understands the difference between "error - could not run the tests",
 "failure - some tests failed", and "success - no test failed".
  ovirt CI sometimes fail successful build because it could not clean up after itself.
- Running on another platform (Ubuntu) - helps to reveal bugs that sometimes
  are hidden on CentOS/Fedora.
  (example: https://github.com/nirs/sanlock/commit/c7fd1b6915c470c6beb191a79c741fb1e6ca9575)
- No vendor lock-in (I don't like to depend on single CI provider)
- I enjoy using it, I don't enjoy gerrit and jenkins

I know that new ovirt CI solved some of the issues, but nobody sent
patches to convert vdsm to the new standard yet.

Issues with travis:
- no integration with gerrit, so people tend to break it
  it wold be nice if we could trigger travis build for every patch, and fail
  the build if travis failed
- need too much manual image rebuilding
- image rebuilds are slow (cost of a free docker account)
- we depend on 3 different services: travis, github, and docker - for single build
 
Travis CI is still failing.


OK (SKIP=63)
mv .coverage .coverage-nose-py2
mv: cannot stat '.coverage': No such file or directory
make[1]: *** [check] Error 1
make[1]: Leaving directory `/vdsm/tests'
ERROR: InvocationError: '/usr/bin/make -C tests check'


I think this is the cause: https://github.com/oVirt/vdsm/commit/6b905c2c134bcf344961d28eefbd05f2838d2ec8

This also seems to be broken when running make locally.
 


    def _run_cmd(cmd, cwd=None):
        rc, out, err = commands.execCmd(cmd, raw=True, cwd=cwd)
        if rc != 0:
>           raise cmdutils.Error(cmd, rc, out, err)
E           Error: Command ['/usr/bin/qemu-img', 'info', '--output', 'json', '-U', '/var/tmp/tmp89QFPD/img.img'] failed with rc=1 out='' err="qemu-img: unrecognized option '-U'\nTry 'qemu-img --help' for more information\n"
../lib/vdsm/storage/qemuimg.py:399: Error

This means we are running old qemu, need to update our images.
I guess this broken in the centos build?
 
this happen 3 times in the job causing the result to be:
 3 failed, 1387 passed, 7 skipped, 125 deselected, 1 xfailed, 9 xpassed in 126.99 seconds 
ERROR: InvocationError: '/vdsm/tests/py-watch 600 pytest -m not (slow or stress) --durations=10 --cov=vdsm.storage --cov-report=html:htmlcov-storage-py27 storage'

Also:
storage-py36 create: /vdsm/.tox/storage-py36
ERROR: InterpreterNotFound: python3.6

This is just a warning that python 3.6 is not available, expected when
running on centos.

Maybe we can eliminate these errors in the CI, since we know what
python version should be tested for every image.

Nir
 


There are also several other errors.




 

 
On Tue, May 8, 2018 at 11:59 AM Nir Soffer <nsoffer@redhat.com> wrote:
There are several issues:

1. coverage fail after this patch:
https://github.com/oVirt/vdsm/commit/6b905c2c134bcf344961d28eefbd05f2838d2ec8

...
pwd
/vdsm/tests
ls .cov*
ls: cannot access .cov*: No such file or directory
make[1]: *** [check] Error 2
make[1]: Leaving directory `/vdsm/tests'

2. pywatch_test - gdb not installed

We need to add gdb and install install python-debuginfo package on
the test images.

self = <pywatch_test.TestPyWatch object at 0x2bbc0d0>
    def test_timeout(self):
        rc, out, err = exec_cmd(['./py-watch', '0.1', 'sleep', '10'])
        assert b'Watched process timed out' in out
>       assert rc == 128 + signal.SIGTERM
E       assert 1 == (128 + 15)
E        +  where 15 = signal.SIGTERM
pywatch_test.py:45: AssertionError
------------------------------ Captured log call -------------------------------
cmdutils.py                151 DEBUG    ./py-watch 0.1 sleep 10 (cwd None)
cmdutils.py                159 DEBUG    FAILED: <err> = 'Traceback (most recent call last):\n  File "./py-watch", line 59, in <module>\n    dump_trace(watched_proc)\n  File "./py-watch", line 32, in dump_trace\n    \'thread apply all py-bt\'])\n  File "/usr/lib64/python2.7/site-packages/subprocess32.py", line 575, in call\n    p = Popen(*popenargs, **kwargs)\n  File "/usr/lib64/python2.7/site-packages/subprocess32.py", line 822, in __init__\n    restore_signals, start_new_session)\n  File "/usr/lib64/python2.7/site-packages/subprocess32.py", line 1567, in _execute_child\n    raise child_exception_type(errno_num, err_msg)\nOSError: [Errno 2] No such file or directory: \'gdb\'\n'; <rc> = 1

Nir

_______________________________________________
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-leave@ovirt.org




--

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D

Red Hat EMEA

sbonazzo@redhat.com   




--

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D

Red Hat EMEA

sbonazzo@redhat.com