September 2017 - Infra - oVirt List Archives

[JIRA] (OVIRT-1627) CI +1 marked only on previous patchset
by Yedidyah Bar David (oVirt JIRA) 04 Sep '17

04 Sep '17

This is a multi-part message in MIME format... ------------=_1504517792-17549-109 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Yedidyah Bar David created OVIRT-1627: ----------------------------------------- Summary: CI +1 marked only on previous patchset Key: OVIRT-1627 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1627 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Yedidyah Bar David Assignee: infra Hi, In [1], patchset 6 was tested by CI while I pushed an update, 7, which only changed the commit message. It finished successfully, and only updated 6. Since 7 is a commit-message-only change, it was never marked or tested. I guess the code that marked +1 should also check all the newer patchsets and mark them too if they should inherit. Thanks, [1] https://gerrit.ovirt.org/77810 -- Didi -- This message was sent by Atlassian {0} (v1001.0.0-SNAPSHOT#100059) ------------=_1504517792-17549-109 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <h3>Yedidyah Bar David created OVIRT-1627:</h3> <pre> Summary: CI +1 marked only on previous patchset Key: OVIRT-1627 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1627 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Yedidyah Bar David Assignee: infra</pre> <p>Hi,</p> <p>In [1], patchset 6 was tested by CI while I pushed an update, 7, which only changed the commit message. It finished successfully, and only updated 6. Since 7 is a commit-message-only change, it was never marked or tested.</p> <p>I guess the code that marked +1 should also check all the newer patchsets and mark them too if they should inherit.</p> <p>Thanks,</p> <p>[1] <a href="https://gerrit.ovirt.org/77810">https://gerrit.ovirt.org/77810</a> — Didi</p> <p>— This message was sent by Atlassian {0} (v1001.0.0-SNAPSHOT#100059)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BCmpYLyz…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1504517792-17549-109--

1 0

[CQ]: 81383, 1 (ovirt-provider-ovn) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 04 Sep '17

04 Sep '17

A system test invoked by the "ovirt-master" change queue including change 81383,1 (ovirt-provider-ovn) failed. However, this change seems not to be the root cause for this failure. Change 80112,39 (ovirt-provider-ovn) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 80112,39 (ovirt-provider-ovn) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/81383/1 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/80112/39 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2263/

1 0

[JIRA] (OVIRT-1625) Patch statuses are not updated in Bugzilla
by Barak Korren (oVirt JIRA) 04 Sep '17

04 Sep '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1625?page=com.atlassian.jira.… ] Barak Korren reassigned OVIRT-1625: ----------------------------------- Assignee: Shlomo Ben David (was: infra) Component/s: Gerrit/git Epic Link: OVIRT-403 Issue Type: Outage (was: Bug) Priority: Highest (was: Medium) > Patch statuses are not updated in Bugzilla > ------------------------------------------ > > Key: OVIRT-1625 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1625 > Project: oVirt - virtualization made easy > Issue Type: Outage > Components: Gerrit/git > Reporter: Denis Chaplygin > Assignee: Shlomo Ben David > Priority: Highest > > When patch is merged in gerrit, it's status is not updated in Bugzilla and patch stays in POST state. > For example, patch 80617 [1] was merged today, but it is still in a POST state at bugzilla [2] > [1] https://gerrit.ovirt.org/#/c/80617/ > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1445199 -- This message was sent by Atlassian {0} (v1001.0.0-SNAPSHOT#100059)

1 0

[JIRA] (OVIRT-1625) Patch statuses are not updated in Bugzilla
by Barak Korren (oVirt JIRA) 04 Sep '17

04 Sep '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1625?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1625: -------------------------------- Epic Link: OVIRT-403 > Patch statuses are not updated in Bugzilla > ------------------------------------------ > > Key: OVIRT-1625 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1625 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Gerrit/git > Reporter: Denis Chaplygin > Assignee: infra > > When patch is merged in gerrit, it's status is not updated in Bugzilla and patch stays in POST state. > For example, patch 80617 [1] was merged today, but it is still in a POST state at bugzilla [2] > [1] https://gerrit.ovirt.org/#/c/80617/ > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1445199 -- This message was sent by Atlassian {0} (v1001.0.0-SNAPSHOT#100059)

1 0

[JIRA] (OVIRT-1626) Java Excpetion during CQ tester pipeline run
by Barak Korren (oVirt JIRA) 04 Sep '17

04 Sep '17

Barak Korren created OVIRT-1626: ----------------------------------- Summary: Java Excpetion during CQ tester pipeline run Key: OVIRT-1626 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1626 Project: oVirt - virtualization made easy Issue Type: New Feature Components: oVirt CI Reporter: Barak Korren Assignee: infra Priority: High The following 'ovirt-master_change-queue-tester' run failed with a Java exception: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2257/ The exception seen in blue ocean is the following: {code} Stashed 1 file(s) Failed to serialize org.jenkinsci.plugins.workflow.support.storage.SimpleXStreamFlowNodeStorage$Tag#actions for class org.jenkinsci.plugins.workflow.support.storage.SimpleXStreamFlowNodeStorage$Tag {code} In the job console one can see a different exception: {code} java.lang.InterruptedException at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1302) at com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:275) at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:111) at org.jenkinsci.plugins.workflow.cps.CpsStepContext.getThreadGroupSynchronously(CpsStepContext.java:248) at org.jenkinsci.plugins.workflow.cps.CpsStepContext.getThreadSynchronously(CpsStepContext.java:237) at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:298) at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:61) at org.jenkinsci.plugins.workflow.steps.StepDescriptor.checkContextAvailability(StepDescriptor.java:258) at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:203) at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:150) at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:108) at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1283) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1177) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1027) at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:42) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113) at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:19) at Script1.mk_ost_runner(Script1.groovy:300) at ___cps.transform___(Native Method) at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57) at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109) at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82) at sun.reflect.GeneratedMethodAccessor613.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72) at com.cloudbees.groovy.cps.impl.ClosureBlock.eval(ClosureBlock.java:46) at com.cloudbees.groovy.cps.Next.step(Next.java:83) at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:173) at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:162) at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:122) at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:261) at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:162) at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:174) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:330) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:82) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:242) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:230) at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:64) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112) at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Finished: FAILURE {code} The exception in the console seem to indicate that the exception is in line 300 of the pipeline script in the mk_ost_runner funtction. Here is the code of the function for reference: {code} 289 def mk_ost_runner(ovirt_release, suit_type, distro) { 290 return { 291 def suit_dir = "$suit_type-suit-$ovirt_release-$distro" 292 // stash an empty file so we don`t get errors in no artifacts get stashed 293 writeFile file: '__no_artifacts_stashed__', text: '' 294 stash includes: '__no_artifacts_stashed__', name: suit_dir 295 try { 296 node('integ-tests') { 297 run_ost_on_node(ovirt_release, suit_type, distro, suit_dir) 298 } 299 } finally { 300 dir("exported-artifacts/$suit_dir") { 301 unstash suit_dir 302 } 303 } 304 } 305 } {code} It looks like the exception seen in the console is a secondary exception that happens because of the failure to stash some files earlier in the code inside the {{basic-suit}} run branch as indicated in the blue ocean display. Looking further at the log, we can fined the following which aligns with what we see in blue ocean (Lines that belong to other run branches had been removed): {code} 19:40:55 Will run the following OST (master) suits: basic, upgrade-from-release, upgrade-from-prevrelease [Pipeline] [basic-suit] { (Branch: basic-suit) [Pipeline] [basic-suit] writeFile [Pipeline] [basic-suit] stash 19:40:55 [basic-suit] Stashed 1 file(s) [Pipeline] [basic-suit] node [Pipeline] [basic-suit] // dir [Pipeline] [basic-suit] } 19:47:04 [basic-suit] Failed in branch basic-suit {code} >From the log above it seems that the actual failure is around line 294 if the function quoted above. -- This message was sent by Atlassian {0} (v1001.0.0-SNAPSHOT#100059)

1 0

[JIRA] (OVIRT-1626) Java Excpetion during CQ tester pipeline run
by Barak Korren (oVirt JIRA) 04 Sep '17

04 Sep '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1626?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1626: -------------------------------- Epic Link: OVIRT-400 > Java Excpetion during CQ tester pipeline run > -------------------------------------------- > > Key: OVIRT-1626 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1626 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > Priority: High > Labels: change-queue, ost_failures > > The following 'ovirt-master_change-queue-tester' run failed with a Java exception: > http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2257/ > The exception seen in blue ocean is the following: > {code} > Stashed 1 file(s) > Failed to serialize org.jenkinsci.plugins.workflow.support.storage.SimpleXStreamFlowNodeStorage$Tag#actions for class org.jenkinsci.plugins.workflow.support.storage.SimpleXStreamFlowNodeStorage$Tag > {code} > In the job console one can see a different exception: > {code} > java.lang.InterruptedException > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1302) > at com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:275) > at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:111) > at org.jenkinsci.plugins.workflow.cps.CpsStepContext.getThreadGroupSynchronously(CpsStepContext.java:248) > at org.jenkinsci.plugins.workflow.cps.CpsStepContext.getThreadSynchronously(CpsStepContext.java:237) > at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:298) > at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:61) > at org.jenkinsci.plugins.workflow.steps.StepDescriptor.checkContextAvailability(StepDescriptor.java:258) > at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:203) > at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:150) > at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:108) > at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1283) > at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1177) > at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1027) > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:42) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48) > at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113) > at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:19) > at Script1.mk_ost_runner(Script1.groovy:300) > at ___cps.transform___(Native Method) > at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57) > at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109) > at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82) > at sun.reflect.GeneratedMethodAccessor613.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72) > at com.cloudbees.groovy.cps.impl.ClosureBlock.eval(ClosureBlock.java:46) > at com.cloudbees.groovy.cps.Next.step(Next.java:83) > at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:173) > at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:162) > at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:122) > at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:261) > at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:162) > at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:174) > at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:330) > at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:82) > at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:242) > at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:230) > at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:64) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112) > at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Finished: FAILURE > {code} > The exception in the console seem to indicate that the exception is in line 300 of the pipeline script in the mk_ost_runner funtction. Here is the code of the function for reference: > {code} > 289 def mk_ost_runner(ovirt_release, suit_type, distro) { > 290 return { > 291 def suit_dir = "$suit_type-suit-$ovirt_release-$distro" > 292 // stash an empty file so we don`t get errors in no artifacts get stashed > 293 writeFile file: '__no_artifacts_stashed__', text: '' > 294 stash includes: '__no_artifacts_stashed__', name: suit_dir > 295 try { > 296 node('integ-tests') { > 297 run_ost_on_node(ovirt_release, suit_type, distro, suit_dir) > 298 } > 299 } finally { > 300 dir("exported-artifacts/$suit_dir") { > 301 unstash suit_dir > 302 } > 303 } > 304 } > 305 } > {code} > It looks like the exception seen in the console is a secondary exception that happens because of the failure to stash some files earlier in the code inside the {{basic-suit}} run branch as indicated in the blue ocean display. Looking further at the log, we can fined the following which aligns with what we see in blue ocean (Lines that belong to other run branches had been removed): > {code} > 19:40:55 Will run the following OST (master) suits: basic, upgrade-from-release, upgrade-from-prevrelease > [Pipeline] [basic-suit] { (Branch: basic-suit) > [Pipeline] [basic-suit] writeFile > [Pipeline] [basic-suit] stash > 19:40:55 [basic-suit] Stashed 1 file(s) > [Pipeline] [basic-suit] node > [Pipeline] [basic-suit] // dir > [Pipeline] [basic-suit] } > 19:47:04 [basic-suit] Failed in branch basic-suit > {code} > From the log above it seems that the actual failure is around line 294 if the function quoted above. -- This message was sent by Atlassian {0} (v1001.0.0-SNAPSHOT#100059)

1 0

oVirt infra daily report - unstable production jobs - 433
by jenkins＠jenkins.phx.ovirt.org 04 Sep '17

04 Sep '17

------=_Part_172_1405506555.1504479606571 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Good morning! Attached is the HTML page with the jenkins status report. You can see it also here: - http://jenkins.ovirt.org/job/system_jenkins-report/433//artifact/exported-a… Cheers, Jenkins ------=_Part_172_1405506555.1504479606571 Content-Type: text/html; charset=us-ascii; name=upstream_report.html Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=upstream_report.html Content-ID: <upstream_report.html> <!DOCTYPE html><head><style type="text/css"> table.gridtable { border-collapse: collapse; table-layout:fixed; width:1600px; font-family: monospace; font-size:13px; } .head { font-size:20px; font-family: arial; } .sub { font-size:18px; background-color:#e5e5e5; font-family: arial; } pre { font-family: monospace; display: inline; white-space: pre-wrap; white-space: -moz-pre-wrap !important; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word; } </style> </head> <body> <table class="gridtable" border=2> <tr><th colspan=2 class=head> RHEVM CI Jenkins Daily Report - 03/09/2017 </th></tr><tr><th colspan=2 class=sub> <font color="blue"><a href="http://jenkins.ovirt.org/">00 Unstable Critical</a></font> </th></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-system-tests_ansible-suite-master/">ovirt-system-tests_ansible-suite-master</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-master/">ovirt-system-tests_hc-basic-suite-master</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/">ovirt-system-tests_he-basic-suite-master</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> ------=_Part_172_1405506555.1504479606571--

1 0

[CQ]: 81160,9 (ovirt-engine) failed "ovirt-master" system tests
by oVirt Jenkins 03 Sep '17

03 Sep '17

Change 81160,9 (ovirt-engine) is probably the reason behind recent system test failures in the "ovirt-master" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/81160/9 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2257/

1 0

[CQ]: 81278, 5 (vdsm) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 03 Sep '17

03 Sep '17

A system test invoked by the "ovirt-master" change queue including change 81278,5 (vdsm) failed. However, this change seems not to be the root cause for this failure. Change 81088,4 (vdsm) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 81088,4 (vdsm) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/81278/5 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/81088/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2255/

1 0

planned Gerrit maintenance
by Evgheni Dereveanchin 03 Sep '17

03 Sep '17

Hi everyone, I will be performing updates on gerrit.ovirt.org during the next two hours. Within this period the Gerrit UI and Git repositories may be unavailable. I will follow up as soon as maintenance activities are over. -- Regards, Evgheni Dereveanchin

5 5