On Thu, Dec 8, 2016 at 12:11 PM, Martin Polednik <mpoled...@redhat.com>
wrote:

> On 08/12/16 11:26 +0200, Edward Haas wrote:
>
>> On Thu, Dec 8, 2016 at 10:12 AM, Martin Polednik <mpoled...@redhat.com>
>> wrote:
>>
>> On 08/12/16 09:28 +0200, Edward Haas wrote:
>>>
>>> On Wed, Dec 7, 2016 at 11:54 PM, Nir Soffer <nsof...@redhat.com> wrote:
>>>>
>>>> broken_on_ci is uses default name="OVIRT_CI", to mark it also for
>>>>
>>>>> travis, we need another broken_on_ci with name="TRAVIS_CI".
>>>>>
>>>>> Maybe this test should run only if nm is active on the machine?
>>>>>
>>>>>
>>>>> We need the test to always run when expected.
>>>> If NM is not running, the test will not run (silently) and we will never
>>>> know if there is a problem or not.
>>>>
>>>> It is not convenient to mark each CI type as broken, why the test code
>>>> needs to know we have multiple
>>>> CI/s?
>>>>
>>>>
>>> I believe this is great point - we should just mark the test as broken
>>> on *any* CI to create a pressure to get it fixed.
>>>
>>> Slight off-topic addition: I don't understand why patch marking a test
>>> as broken on CI takes more than 5 minutes to get merged in when given
>>> pointer to the failure.
>>>
>>
>>
>> Because it is a wrong approach. :)
>> If a test fails, it is a smell that something bad happens and we may have
>> a
>> production problem.
>> So before marking and excluding the test, one should feel very guilty that
>> this check is no longer covered and better understand why it fails.
>>
>
> Those are 1-in-N case breakages. The fact the test is unstable should
> be noted by a maintainer, but shouldn't block any other patches or
> series (which is what often happens).
>
> I don't feel any guilt marking bad test as bad.


How do you know if it is a bad test, bad production code or perhaps even a
bad
3rd party library/driver etc...?
In most cases, the test just checks that what we expect from the code
indeed happens.
If our expectations are not valid, we have a bad test, but if our
expectations are valid, killing
the test just hides the problem.

Regarding the blocking part, I agree, it is indeed a problem. Except
splitting a project into
smaller pieces I don't know of a good solution for that. (introducing other
problems)
(When you are small, you can run faster. I think this is the micro-services
way)


>
>
>
>>
>>>
>>> Currently, we run on CI tests that are not marked as 'functional'.
>>>
>>>> Perhaps we need another test type that can be mark not to run on simple
>>>> CI.
>>>> "power-integration", "super-integration"?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Wed, Dec 7, 2016 at 11:23 PM, Dan Kenigsberg <dan...@redhat.com>
>>>>> wrote:
>>>>> > On Wed, Dec 7, 2016 at 2:03 PM, Nir Soffer <nsof...@redhat.com>
>>>>> wrote:
>>>>> >> Looks like we need @brokentest("reason...", name="TRAVIC_CI") on
>>>>> this:
>>>>> >
>>>>> > Odd, the code already has
>>>>> >
>>>>> > @broken_on_ci('NetworkManager should not be started on CI nodes')
>>>>> >
>>>>> >
>>>>> >>
>>>>> >> See https://travis-ci.org/oVirt/vdsm/jobs/181933329
>>>>> >>
>>>>> >> ============================================================
>>>>> ==========
>>>>> >>
>>>>> >> ERROR: test suite for <module 'network.nmdbus_test' from
>>>>> >> '/vdsm/tests/network/nmdbus_test.py'>
>>>>> >>
>>>>> >> ------------------------------------------------------------
>>>>> ----------
>>>>> >>
>>>>> >> Traceback (most recent call last):
>>>>> >>
>>>>> >>   File "/usr/lib/python2.7/site-packages/nose/suite.py", line 209,
>>>>> in
>>>>> run
>>>>> >>
>>>>> >>     self.setUp()
>>>>> >>
>>>>> >>   File "/usr/lib/python2.7/site-packages/nose/suite.py", line 292,
>>>>> in
>>>>> setUp
>>>>> >>
>>>>> >>     self.setupContext(ancestor)
>>>>> >>
>>>>> >>   File "/usr/lib/python2.7/site-packages/nose/suite.py", line 315,
>>>>> in
>>>>> >> setupContext
>>>>> >>
>>>>> >>     try_run(context, names)
>>>>> >>
>>>>> >>   File "/usr/lib/python2.7/site-packages/nose/util.py", line 471,
>>>>> in
>>>>> try_run
>>>>> >>
>>>>> >>     return func()
>>>>> >>
>>>>> >>   File "/vdsm/tests/testValidation.py", line 191, in wrapper
>>>>> >>
>>>>> >>     return f(*args, **kwargs)
>>>>> >>
>>>>> >>   File "/vdsm/tests/testValidation.py", line 97, in wrapper
>>>>> >>
>>>>> >>     return f(*args, **kwargs)
>>>>> >>
>>>>> >>   File "/vdsm/tests/network/nmdbus_test.py", line 48, in
>>>>> setup_module
>>>>> >>
>>>>> >>     NMDbus.init()
>>>>> >>
>>>>> >>   File "/vdsm/lib/vdsm/network/nm/nmdbus/__init__.py", line 33, in
>>>>> init
>>>>> >>
>>>>> >>     NMDbus.bus = dbus.SystemBus()
>>>>> >>
>>>>> >>   File "/usr/lib64/python2.7/site-packages/dbus/_dbus.py", line
>>>>> 194,
>>>>> in __new__
>>>>> >>
>>>>> >>     private=private)
>>>>> >>
>>>>> >>   File "/usr/lib64/python2.7/site-packages/dbus/_dbus.py", line
>>>>> 100,
>>>>> in __new__
>>>>> >>
>>>>> >>     bus = BusConnection.__new__(subclass, bus_type,
>>>>> mainloop=mainloop)
>>>>> >>
>>>>> >>   File "/usr/lib64/python2.7/site-packages/dbus/bus.py", line 122,
>>>>> in
>>>>> __new__
>>>>> >>
>>>>> >>     bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
>>>>> >>
>>>>> >> DBusException: org.freedesktop.DBus.Error.FileNotFound: Failed to
>>>>> >> connect to socket /var/run/dbus/system_bus_socket: No such file or
>>>>> >> directory
>>>>> >>
>>>>> >> -------------------- >> begin captured logging <<
>>>>> --------------------
>>>>> >>
>>>>> >> 2016-12-07 11:48:33,458 DEBUG (MainThread) [root] /usr/bin/taskset
>>>>> >> --cpu-list 0-1 /bin/systemctl status NetworkManager (cwd None)
>>>>> >> (commands:69)
>>>>> >>
>>>>> >> 2016-12-07 11:48:33,465 DEBUG (MainThread) [root] FAILED: <err> =
>>>>> >> 'Failed to get D-Bus connection: Operation not permitted\n'; <rc> =
>>>>> 1
>>>>> >> (commands:93)
>>>>> >>
>>>>> >> 2016-12-07 11:48:33,465 DEBUG (MainThread) [root] /usr/bin/taskset
>>>>> >> --cpu-list 0-1 /bin/systemctl start NetworkManager (cwd None)
>>>>> >> (commands:69)
>>>>> >>
>>>>> >> 2016-12-07 11:48:33,470 DEBUG (MainThread) [root] FAILED: <err> =
>>>>> >> 'Failed to get D-Bus connection: Operation not permitted\n'; <rc> =
>>>>> 1
>>>>> >> (commands:93)
>>>>> >>
>>>>> >> --------------------- >> end captured logging <<
>>>>> ---------------------
>>>>>
>>>>>
>>>>> _______________________________________________
>>>
>>>> Devel mailing list
>>>> Devel@ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>
>>>>
>>>
>>>
_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.phx.ovirt.org/mailman/listinfo/devel

Reply via email to