On Thu, May 31, 2018 at 10:34 AM Sandro Bonazzola <sbona...@redhat.com>
wrote:

> 2018-05-16 17:12 GMT+02:00 Sandro Bonazzola <sbona...@redhat.com>:
>
>>
>>
>> 2018-05-16 15:20 GMT+02:00 Nir Soffer <nsof...@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
<https://travis-ci.org/oVirt/vdsm/builds/386053193?utm_source=github_status&utm_medium=notification>
  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.
> https://travis-ci.org/oVirt/vdsm/jobs/386053194
>
>
> 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 <nsof...@redhat.com> wrote:
>>>
>>>> There are several issues:
>>>>
>>>> 1. coverage fail after this patch:
>>>>
>>>> https://github.com/oVirt/vdsm/commit/6b905c2c134bcf344961d28eefbd05f2838d2ec8
>>>>
>>>> https://travis-ci.org/oVirt/vdsm/builds/366574414
>>>> ...
>>>> 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-le...@ovirt.org
>>>
>>>
>>
>>
>> --
>>
>> SANDRO BONAZZOLA
>>
>> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>>
>> Red Hat EMEA <https://www.redhat.com/>
>>
>> sbona...@redhat.com
>> <https://red.ht/sig>
>> <https://redhat.com/summit>
>>
>
>
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>
> Red Hat EMEA <https://www.redhat.com/>
>
> sbona...@redhat.com
> <https://red.ht/sig>
> <https://redhat.com/summit>
>
_______________________________________________
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/HAODBN6L7SIT6SCRGHXUB4M67BEPX7A4/

Reply via email to