[ovirt-devel] [ OST Failure Report ] [ oVirt 4.2 ] [ 002_bootstrap.update_default_cluster ]

Tue Mar 13 21:49:10 UTC 2018

On Tue, Mar 13, 2018 at 9:32 PM, Michal Skrivanek <
michal.skrivanek at redhat.com> wrote:

>
>
> On 13 Mar 2018, at 22:24, Dafna Ron <dron at redhat.com> wrote:
>
>
>
> On Tue, Mar 13, 2018 at 10:57 AM, Michal Skrivanek <
> michal.skrivanek at redhat.com> wrote:
>
>>
>>
>> On 13 Mar 2018, at 09:27, Eyal Edri <eedri at redhat.com> wrote:
>>
>>
>>
>> On Tue, Mar 13, 2018 at 9:29 AM, Dan Kenigsberg <danken at redhat.com>
>> wrote:
>>
>>> On Mon, Mar 12, 2018 at 8:24 PM, Dafna Ron <dron at redhat.com> wrote:
>>> > We just had a failure in master 002_bootstrap.add_mac_pool with the
>>> same
>>> > error on edit cluster.
>>>
>>
>> Does it fail consistently?
>>
>
> yes.
>
>
> that’s good
>
>
>
>
>> Did you narrow down the commit(s) where it started to happen?
>>
>
> First change reported failed by CQ on this issue is this one:
> https://gerrit.ovirt.org/#/c/88738/2
>  - db: add func to turn table columns to empty string  (this was reported
> by Daniel at the beginning of this thread)
>
> Was there any other update done at that time?
>>
>> there are always other changes submitted. but CQ tries to isolate the
> change that it believes is causing the failure by reducing the change it
> tests until it gets to one single change.
>
>
> I meant changes like major update of packages or any other configuration
> change
>

:) the last one I saw was from Eli on Friday but I don't think its related.
since this is a big project and there a lot of changes submitted daily,
maybe someone more qualified them me can have a look and see if anything
catches their eyes?

>
>
> We cannot have OST keep failing for a long time, especially on a big
> project like ovirt-engine. if we cannot have a fix on this quickly I think
> we should start skipping failed tests to allow changes to pass successfully
> until the bug is fixed.
>
>
> sure. But in this case you’re just going to hit the same problem in the
> next test. Please enable back the one you commented out, and try to revert
> that patch instead. There is a chance it changed the behavior because
> somehow the tests using Default cluster somehow rely on undefined values
> (not sure if that’s even intentional, but that’s the way it is written),
> and that patch may have changed it perhaps. Eli?
>
> cool. I think that Eyal has reverted my skip test so we can try to revert
the change reported.

> Thanks,
> michal
>
>
> Thanks,
> Dafna
>
>
>
>> Thanks,
>> michal
>>
>> >
>>> > http://jenkins.ovirt.org/job/ovirt-master_change-queue-teste
>>> r/6259/testReport/(root)/002_bootstrap/add_mac_pool/
>>> >
>>> > either I skipped the wrong test or we have a bigger issue.
>>>
>>> We certainly do. As before, the error pops up on an attempt to update
>>> the cluster (this time it is changing only the mac pool of the
>>> cluster). CPU is not specified by the command, so it should not have
>>> changed at all. Still, something fills a CPU, and chooses a wrong
>>> value.
>>>
>>>         cluster_service.update(
>>>             cluster=sdk4.types.Cluster(
>>>                 mac_pool=sdk4.types.MacPool(
>>>                     id=pool.id,
>>>                 )
>>>             )
>>>         )
>>>
>>> 2018-03-12 13:58:56,263-04 WARN
>>> [org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-19)
>>> [79d12090-a8e8-438c-bbce-1bf09a42c5fb] Validation of action
>>> 'UpdateCluster' failed for user admin at internal-authz. Reasons:
>>> VAR__TYPE__CLUSTER,VAR__ACTION__UPDATE,ACTION_TYPE_FAILED_CP
>>> U_NOT_FOUND,VAR__TYPE__CLUSTER
>>> 2018-03-12 13:58:56,264-04 INFO
>>> [org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-19)
>>> [79d12090-a8e8-438c-bbce-1bf09a42c5fb] Lock freed to object
>>> 'EngineLock:{exclusiveLocks='[]', sharedLocks='[]'}'
>>> 2018-03-12 13:58:56,264-04 DEBUG
>>> [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
>>> (default task-19) [79d12090-a8e8-438c-bbce-1bf09a42c5fb] method:
>>> runAction, params: [UpdateCluster,
>>> ManagementNetworkOnClusterOperationParameters:{commandId='be
>>> be80f7-f8ca-4d01-aed8-28e463d0f435',
>>> user='null', commandType='Unknown'}], timeElapsed: 50ms
>>> 2018-03-12 13:58:56,269-04 ERROR
>>> [org.ovirt.engine.api.restapi.resource.AbstractBackendResource]
>>> (default task-19) [] Operation Failed: [Cannot edit Cluster. The
>>> chosen CPU is not supported.]
>>>
>>
>> So I guess we can't skip this test as well, and this issue has to be
>> fixed right?
>>
>>
>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>>
>> --
>> Eyal edri
>>
>> MANAGER
>>
>> RHV DevOps
>>
>> EMEA VIRTUALIZATION R&D
>>
>>
>> Red Hat EMEA <https://www.redhat.com/>
>> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>> phone: +972-9-7692018 <+972%209-769-2018>
>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>> _______________________________________________
>> Devel mailing list
>> Devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20180313/e9cc7827/attachment.html>