- Infra - oVirt List Archives

[CQ]: 102610, 5 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 28 Aug '19

28 Aug '19

A system test invoked by the "ovirt-master" change queue including change 102610,5 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/102610/5 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15587/

1 0

[JIRA] (OVIRT-2784) please update maintainers for ovirt-engine-nodejs-modules
by Michal Skrivanek (oVirt JIRA) 28 Aug '19

28 Aug '19

Michal Skrivanek created OVIRT-2784: --------------------------------------- Summary: please update maintainers for ovirt-engine-nodejs-modules Key: OVIRT-2784 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2784 Project: oVirt - virtualization made easy Issue Type: Task Reporter: Michal Skrivanek Assignee: infra as per https://lists.ovirt.org/archives/list/devel@ovirt.org/thread/S3ULX7EQZ7YHRM… -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100108)

1 0

[JIRA] (OVIRT-2780) Fwd: [ovirt-devel] jenkins CI failing to fetch repo
by Anton Marchukov (oVirt JIRA) 28 Aug '19

28 Aug '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2780?page=com.atlassian.jira.… ] Anton Marchukov reassigned OVIRT-2780: -------------------------------------- Assignee: Evgheni Dereveanchin (was: infra) > Fwd: [ovirt-devel] jenkins CI failing to fetch repo > --------------------------------------------------- > > Key: OVIRT-2780 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2780 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Ehud Yonasi > Assignee: Evgheni Dereveanchin > > ---------- Forwarded message --------- > From: Miguel Duarte de Mora Barroso <mdbarroso(a)redhat.com> > Date: Thu, Aug 22, 2019 at 11:02 AM > Subject: [ovirt-devel] jenkins CI failing to fetch repo > To: oVirt devel <devel(a)ovirt.org>, oVirt Jenkins <jenkins(a)ovirt.org> > Hi, > Since yesterday I can't get ovirt-provider-ovn builds to run, each > manifesting the error below: > error: index-pack died of signal 15 > 09:27:35 fatal: index-pack failed > 09:27:35 > 09:27:35 at > org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2042) > 09:27:35 at > org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1761) > 09:27:35 at > org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$400(CliGitAPIImpl.java:72) > 09:27:35 at > org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:442) > 09:27:35 at > org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:655) > 09:27:35 at > org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153) > 09:27:35 at > org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146) > 09:27:35 at hudson.remoting.UserRequest.perform(UserRequest.java:212) > 09:27:35 at hudson.remoting.UserRequest.perform(UserRequest.java:54) > 09:27:35 at hudson.remoting.Request$2.run(Request.java:369) > 09:27:35 at > hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) > 09:27:35 at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 09:27:35 at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > 09:27:35 at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > 09:27:35 at java.lang.Thread.run(Thread.java:748) > 09:27:35 Suppressed: hudson.remoting.Channel$CallSiteStackTrace: > Remote call to vm0038.workers-phx.ovirt.org > 09:27:35 at > hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743) > 09:27:35 at > hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) > 09:27:35 at hudson.remoting.Channel.call(Channel.java:957) > 09:27:35 at > org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146) > 09:27:35 at sun.reflect.GeneratedMethodAccessor793.invoke(Unknown Source) > 09:27:35 at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > 09:27:35 at java.lang.reflect.Method.invoke(Method.java:498) > 09:27:35 at > org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132) > 09:27:35 at com.sun.proxy.$Proxy118.execute(Unknown Source) > 09:27:35 at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1152) > 09:27:35 at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192) > 09:27:35 at > org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:124) > 09:27:35 at > org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:93) > 09:27:35 at > org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:80) > 09:27:35 at > org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47) > 09:27:35 at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > 09:27:35 ... 4 more > It can be seen on: > - > https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-check-patch/2476/… > _______________________________________________ > Devel mailing list -- devel(a)ovirt.org > To unsubscribe send an email to devel-leave(a)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/XOYJOK4AXT7AK… -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100108)

1 0

oVirt infra daily report - unstable production jobs - 930
by jenkins＠jenkins.phx.ovirt.org 28 Aug '19

28 Aug '19

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/930//artifact/exported-a… Cheers, Jenkins

1 0

[CQ]: 102861, 1 (ovirt-host-deploy) failed "ovirt-4.3" system tests, but isn't the failure root cause
by oVirt Jenkins 27 Aug '19

27 Aug '19

A system test invoked by the "ovirt-4.3" change queue including change 102861,1 (ovirt-host-deploy) failed. However, this change seems not to be the root cause for this failure. Change 102426,5 (ovirt-host-deploy) 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 102426,5 (ovirt-host-deploy) 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/102861/1 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/102426/5 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.3_change-queue-tester/1918/

1 0

[CQ]: 102839, 2 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 27 Aug '19

27 Aug '19

A system test invoked by the "ovirt-master" change queue including change 102839,2 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/102839/2 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15580/

1 0

[CQ]: 8af0004 (ovirt-ansible-vm-infra) failed "ovirt-master" system tests
by oVirt Jenkins 27 Aug '19

27 Aug '19

Change 8af0004 (ovirt-ansible-vm-infra) 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://github.com/oVirt/ovirt-ansible-vm-infra/commit/8af000487c9442a3f09f… For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15575/

1 0

[CQ]: 101402, 10 (ovirt-engine-api-model) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 27 Aug '19

27 Aug '19

A system test invoked by the "ovirt-master" change queue including change 101402,10 (ovirt-engine-api-model) failed. However, this change seems not to be the root cause for this failure. Change 102344,1 (ovirt-engine-api-model) 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 102344,1 (ovirt-engine-api- model) 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/101402/10 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/102344/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15572/

1 0

[CQ]: 102860, 1 (ovirt-host-deploy) failed "ovirt-4.3" system tests, but isn't the failure root cause
by oVirt Jenkins 27 Aug '19

27 Aug '19

A system test invoked by the "ovirt-4.3" change queue including change 102860,1 (ovirt-host-deploy) failed. However, this change seems not to be the root cause for this failure. Change 102426,5 (ovirt-host-deploy) 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 102426,5 (ovirt-host-deploy) 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/102860/1 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/102426/5 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.3_change-queue-tester/1908/

1 0

[CQ]: 101267, 8 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 27 Aug '19

27 Aug '19

A system test invoked by the "ovirt-master" change queue including change 101267,8 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/101267/8 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15569/

1 0

[CQ]: 102761, 10 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 27 Aug '19

27 Aug '19

A system test invoked by the "ovirt-master" change queue including change 102761,10 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/102761/10 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15565/

1 0

[CQ]: 98257, 23 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 27 Aug '19

27 Aug '19

A system test invoked by the "ovirt-master" change queue including change 98257,23 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/98257/23 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15562/

1 0

[CQ]: 101094, 16 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 27 Aug '19

27 Aug '19

A system test invoked by the "ovirt-master" change queue including change 101094,16 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/101094/16 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15558/

1 0

[CQ]: 102713, 7 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 27 Aug '19

27 Aug '19

A system test invoked by the "ovirt-master" change queue including change 102713,7 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/102713/7 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15554/

1 0

[CQ]: 102650, 14 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 27 Aug '19

27 Aug '19

A system test invoked by the "ovirt-master" change queue including change 102650,14 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/102650/14 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15550/

1 0

oVirt infra daily report - unstable production jobs - 929
by jenkins＠jenkins.phx.ovirt.org 27 Aug '19

27 Aug '19

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/929//artifact/exported-a… Cheers, Jenkins

1 0

[CQ]: 102608, 13 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 26 Aug '19

26 Aug '19

A system test invoked by the "ovirt-master" change queue including change 102608,13 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/102608/13 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15546/

1 0

[CQ]: 102642, 11 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 26 Aug '19

26 Aug '19

A system test invoked by the "ovirt-master" change queue including change 102642,11 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/102642/11 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15542/

1 0

[CQ]: 102625, 13 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 26 Aug '19

26 Aug '19

A system test invoked by the "ovirt-master" change queue including change 102625,13 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/102625/13 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15538/

1 0

[CQ]: 102485, 16 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 26 Aug '19

26 Aug '19

A system test invoked by the "ovirt-master" change queue including change 102485,16 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/102485/16 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15534/

1 0

[CQ]: 102426,5 (ovirt-host-deploy) failed "ovirt-4.3" system tests
by oVirt Jenkins 26 Aug '19

26 Aug '19

Change 102426,5 (ovirt-host-deploy) is probably the reason behind recent system test failures in the "ovirt-4.3" 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/102426/5 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.3_change-queue-tester/1903/

1 0

[CQ]: 102508, 15 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 26 Aug '19

26 Aug '19

A system test invoked by the "ovirt-master" change queue including change 102508,15 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/102508/15 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15529/

1 0

[CQ]: 102542, 17 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 26 Aug '19

26 Aug '19

A system test invoked by the "ovirt-master" change queue including change 102542,17 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/102542/17 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15524/

1 0

[JIRA] (OVIRT-2783) CI fails - tox error
by Eyal Edri (oVirt JIRA) 26 Aug '19

26 Aug '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2783?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-2783: ----------------------------- Resolution: Fixed Status: Done (was: To Do) closing as this isn't an infra issue, will be solved on dev side. > CI fails - tox error > -------------------- > > Key: OVIRT-2783 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2783 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Pavel Bar > Assignee: infra > > Hi, > We experience problems with failed CI on VDSM patches. > Examples: > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10633/ > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10634/ > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10635/ > This is what we see in logs: > out=`tox --version`; \ > if [ $? -ne 0 ]; then \ > echo "Error: cannot run tox, please install tox \ > 2.9.1 or later"; \ > exit 1; \ > fi; \ > version=`echo $out | cut -d' ' -f1`; \ > if python2.7 build-aux/vercmp $version 2.9.1; then \ > echo "Error: tox is too old, please install tox \ > 2.9.1 or later"; \ > exit 1; \ > fi > Traceback (most recent call last): > File "/usr/bin/tox", line 7, in <module> > from tox import cmdline > File "/usr/lib/python2.7/site-packages/tox/__init__.py", line 4, in > <module> > from .hookspecs import hookimpl > File "/usr/lib/python2.7/site-packages/tox/hookspecs.py", line 4, in > <module> > from pluggy import HookimplMarker > File "/usr/lib/python2.7/site-packages/pluggy/__init__.py", line 16, in > <module> > from .manager import PluginManager, PluginValidationError > File "/usr/lib/python2.7/site-packages/pluggy/manager.py", line 6, in > <module> > import importlib_metadata > File "/usr/lib/python2.7/site-packages/importlib_metadata/__init__.py", > line 9, in <module> > import zipp > File "/usr/lib/python2.7/site-packages/zipp.py", line 12, in <module> > import more_itertools > File "/usr/lib/python2.7/site-packages/more_itertools/__init__.py", line > 1, in <module> > from more_itertools.more import * # noqa > File "/usr/lib/python2.7/site-packages/more_itertools/more.py", line 340 > def _collate(*iterables, key=lambda a: a, reverse=False): > ^ > SyntaxError: invalid syntax > Error: cannot run tox, please install tox 2.9.1 or later > make: *** [tox] Error 1 > + teardown > + res=2 > + '[' 2 -ne 0 ']' > + echo '*** err: 2' > *** err: 2 > + collect_logs > + tar --directory /var/log --exclude 'journal/*' -czf > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/mock_varlogs.tar.gz > . > + tar --directory /var/host_log --exclude 'journal/*' -czf > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/host_varlogs.tar.gz > . > + teardown_storage > + python2 tests/storage/userstorage.py teardown > Can someone look at it? > Thank you in advance! > Pavel -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100107)

1 0

[JIRA] (OVIRT-2783) CI fails - tox error
by Pavel Bar (oVirt JIRA) 26 Aug '19

26 Aug '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2783?page=com.atlassian.jira.… ] Pavel Bar commented on OVIRT-2783: ---------------------------------- Hi, Thanks! :) Will it be merged today? On Mon, Aug 26, 2019 at 6:25 PM Marcin Sobczyk <msobczyk(a)redhat.com> wrote: > Hi, > > it's a known issue: > > > https://stackoverflow.com/questions/54648246/invalid-syntax-in-more-itertoo… > > Posted a patch for this: > > https://gerrit.ovirt.org/#/c/102849/ > > Regards, Marcin > On 8/25/19 8:04 PM, Nir Soffer wrote: > > > > On Sun, Aug 25, 2019, 15:19 Pavel Bar <pbar(a)redhat.com> wrote: > >> Hi, >> We experience problems with failed CI on VDSM patches. >> > > Does it work locally and in travis? > > Examples: >> http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10633/ >> http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10634/ >> http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10635/ >> >> This is what we see in logs: >> >> out=`tox --version`; \ >> if [ $? -ne 0 ]; then \ >> echo "Error: cannot run tox, please install tox \ >> 2.9.1 or later"; \ >> exit 1; \ >> fi; \ >> version=`echo $out | cut -d' ' -f1`; \ >> if python2.7 build-aux/vercmp $version 2.9.1; then \ >> echo "Error: tox is too old, please install tox \ >> 2.9.1 or later"; \ >> exit 1; \ >> fi >> Traceback (most recent call last): >> File "/usr/bin/tox", line 7, in <module> >> from tox import cmdline >> File "/usr/lib/python2.7/site-packages/tox/__init__.py", line 4, in >> <module> >> from .hookspecs import hookimpl >> File "/usr/lib/python2.7/site-packages/tox/hookspecs.py", line 4, in >> <module> >> from pluggy import HookimplMarker >> File "/usr/lib/python2.7/site-packages/pluggy/__init__.py", line 16, in >> <module> >> from .manager import PluginManager, PluginValidationError >> File "/usr/lib/python2.7/site-packages/pluggy/manager.py", line 6, in >> <module> >> import importlib_metadata >> File "/usr/lib/python2.7/site-packages/importlib_metadata/__init__.py", >> line 9, in <module> >> import zipp >> File "/usr/lib/python2.7/site-packages/zipp.py", line 12, in <module> >> import more_itertools >> File "/usr/lib/python2.7/site-packages/more_itertools/__init__.py", >> line 1, in <module> >> from more_itertools.more import * # noqa >> File "/usr/lib/python2.7/site-packages/more_itertools/more.py", line 340 >> def _collate(*iterables, key=lambda a: a, reverse=False): >> ^ >> SyntaxError: invalid syntax >> Error: cannot run tox, please install tox 2.9.1 or later >> make: *** [tox] Error 1 >> + teardown >> + res=2 >> + '[' 2 -ne 0 ']' >> + echo '*** err: 2' >> *** err: 2 >> + collect_logs >> + tar --directory /var/log --exclude 'journal/*' -czf >> /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/mock_varlogs.tar.gz >> . >> + tar --directory /var/host_log --exclude 'journal/*' -czf >> /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/host_varlogs.tar.gz >> . >> + teardown_storage >> + python2 tests/storage/userstorage.py teardown >> >> Can someone look at it? >> >> Thank you in advance! >> >> Pavel >> >> _______________________________________________ >> Devel mailing list -- devel(a)ovirt.org >> To unsubscribe send an email to devel-leave(a)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/VADZM35IRVN4E… >> > > _______________________________________________ > Devel mailing list -- devel(a)ovirt.org > To unsubscribe send an email to devel-leave(a)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/AVD6QSBEPRTDY… > > > CI fails - tox error > -------------------- > > Key: OVIRT-2783 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2783 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Pavel Bar > Assignee: infra > > Hi, > We experience problems with failed CI on VDSM patches. > Examples: > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10633/ > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10634/ > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10635/ > This is what we see in logs: > out=`tox --version`; \ > if [ $? -ne 0 ]; then \ > echo "Error: cannot run tox, please install tox \ > 2.9.1 or later"; \ > exit 1; \ > fi; \ > version=`echo $out | cut -d' ' -f1`; \ > if python2.7 build-aux/vercmp $version 2.9.1; then \ > echo "Error: tox is too old, please install tox \ > 2.9.1 or later"; \ > exit 1; \ > fi > Traceback (most recent call last): > File "/usr/bin/tox", line 7, in <module> > from tox import cmdline > File "/usr/lib/python2.7/site-packages/tox/__init__.py", line 4, in > <module> > from .hookspecs import hookimpl > File "/usr/lib/python2.7/site-packages/tox/hookspecs.py", line 4, in > <module> > from pluggy import HookimplMarker > File "/usr/lib/python2.7/site-packages/pluggy/__init__.py", line 16, in > <module> > from .manager import PluginManager, PluginValidationError > File "/usr/lib/python2.7/site-packages/pluggy/manager.py", line 6, in > <module> > import importlib_metadata > File "/usr/lib/python2.7/site-packages/importlib_metadata/__init__.py", > line 9, in <module> > import zipp > File "/usr/lib/python2.7/site-packages/zipp.py", line 12, in <module> > import more_itertools > File "/usr/lib/python2.7/site-packages/more_itertools/__init__.py", line > 1, in <module> > from more_itertools.more import * # noqa > File "/usr/lib/python2.7/site-packages/more_itertools/more.py", line 340 > def _collate(*iterables, key=lambda a: a, reverse=False): > ^ > SyntaxError: invalid syntax > Error: cannot run tox, please install tox 2.9.1 or later > make: *** [tox] Error 1 > + teardown > + res=2 > + '[' 2 -ne 0 ']' > + echo '*** err: 2' > *** err: 2 > + collect_logs > + tar --directory /var/log --exclude 'journal/*' -czf > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/mock_varlogs.tar.gz > . > + tar --directory /var/host_log --exclude 'journal/*' -czf > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/host_varlogs.tar.gz > . > + teardown_storage > + python2 tests/storage/userstorage.py teardown > Can someone look at it? > Thank you in advance! > Pavel -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100107)

1 0

[CQ]: 102449, 16 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 26 Aug '19

26 Aug '19

A system test invoked by the "ovirt-master" change queue including change 102449,16 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/102449/16 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15519/

1 0

[JIRA] (OVIRT-2783) CI fails - tox error
by Marcin Sobczyk (oVirt JIRA) 26 Aug '19

26 Aug '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2783?page=com.atlassian.jira.… ] Marcin Sobczyk commented on OVIRT-2783: --------------------------------------- Hi, it's a known issue: https://stackoverflow.com/questions/54648246/invalid-syntax-in-more-itertoo… Posted a patch for this: https://gerrit.ovirt.org/#/c/102849/ Regards, Marcin On 8/25/19 8:04 PM, Nir Soffer wrote: > > > On Sun, Aug 25, 2019, 15:19 Pavel Bar <pbar(a)redhat.com > <mailto:pbar@redhat.com>> wrote: > > Hi, > We experience problems with failed CI on VDSM patches. > > > Does it work locally and in travis? > > Examples: > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10633/ > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10634/ > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10635/ > > This is what we see in logs: > > out=`tox --version`; \ > if [ $? -ne 0 ]; then \ > echo "Error: cannot run tox, please install tox \ > 2.9.1 or later"; \ > exit 1; \ > fi; \ > version=`echo $out | cut -d' ' -f1`; \ > if python2.7 build-aux/vercmp $version 2.9.1; then \ > echo "Error: tox is too old, please install tox \ > 2.9.1 or later"; \ > exit 1; \ > fi > Traceback (most recent call last): > File "/usr/bin/tox", line 7, in <module> > from tox import cmdline > File "/usr/lib/python2.7/site-packages/tox/__init__.py", line 4, > in <module> > from .hookspecs import hookimpl > File "/usr/lib/python2.7/site-packages/tox/hookspecs.py", line > 4, in <module> > from pluggy import HookimplMarker > File "/usr/lib/python2.7/site-packages/pluggy/__init__.py", line > 16, in <module> > from .manager import PluginManager, PluginValidationError > File "/usr/lib/python2.7/site-packages/pluggy/manager.py", line > 6, in <module> > import importlib_metadata > File > "/usr/lib/python2.7/site-packages/importlib_metadata/__init__.py", > line 9, in <module> > import zipp > File "/usr/lib/python2.7/site-packages/zipp.py", line 12, in > <module> > import more_itertools > File > "/usr/lib/python2.7/site-packages/more_itertools/__init__.py", > line 1, in <module> > from more_itertools.more import * # noqa > File "/usr/lib/python2.7/site-packages/more_itertools/more.py", > line 340 > def _collate(*iterables, key=lambda a: a, reverse=False): > ^ > SyntaxError: invalid syntax > Error: cannot run tox, please install tox 2.9.1 or later > make: *** [tox] Error 1 > + teardown > + res=2 > + '[' 2 -ne 0 ']' > + echo '*** err: 2' > *** err: 2 > + collect_logs > + tar --directory /var/log --exclude 'journal/*' -czf > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/mock_varlogs.tar.gz > . > + tar --directory /var/host_log --exclude 'journal/*' -czf > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/host_varlogs.tar.gz > . > + teardown_storage > + python2 tests/storage/userstorage.py teardown > > Can someone look at it? > > Thank you in advance! > > Pavel > > _______________________________________________ > Devel mailing list -- devel(a)ovirt.org <mailto:devel@ovirt.org> > To unsubscribe send an email to devel-leave(a)ovirt.org > <mailto:devel-leave@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/VADZM35IRVN4E… > > > _______________________________________________ > Devel mailing list -- devel(a)ovirt.org > To unsubscribe send an email to devel-leave(a)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/AVD6QSBEPRTDY… > CI fails - tox error > -------------------- > > Key: OVIRT-2783 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2783 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Pavel Bar > Assignee: infra > > Hi, > We experience problems with failed CI on VDSM patches. > Examples: > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10633/ > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10634/ > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10635/ > This is what we see in logs: > out=`tox --version`; \ > if [ $? -ne 0 ]; then \ > echo "Error: cannot run tox, please install tox \ > 2.9.1 or later"; \ > exit 1; \ > fi; \ > version=`echo $out | cut -d' ' -f1`; \ > if python2.7 build-aux/vercmp $version 2.9.1; then \ > echo "Error: tox is too old, please install tox \ > 2.9.1 or later"; \ > exit 1; \ > fi > Traceback (most recent call last): > File "/usr/bin/tox", line 7, in <module> > from tox import cmdline > File "/usr/lib/python2.7/site-packages/tox/__init__.py", line 4, in > <module> > from .hookspecs import hookimpl > File "/usr/lib/python2.7/site-packages/tox/hookspecs.py", line 4, in > <module> > from pluggy import HookimplMarker > File "/usr/lib/python2.7/site-packages/pluggy/__init__.py", line 16, in > <module> > from .manager import PluginManager, PluginValidationError > File "/usr/lib/python2.7/site-packages/pluggy/manager.py", line 6, in > <module> > import importlib_metadata > File "/usr/lib/python2.7/site-packages/importlib_metadata/__init__.py", > line 9, in <module> > import zipp > File "/usr/lib/python2.7/site-packages/zipp.py", line 12, in <module> > import more_itertools > File "/usr/lib/python2.7/site-packages/more_itertools/__init__.py", line > 1, in <module> > from more_itertools.more import * # noqa > File "/usr/lib/python2.7/site-packages/more_itertools/more.py", line 340 > def _collate(*iterables, key=lambda a: a, reverse=False): > ^ > SyntaxError: invalid syntax > Error: cannot run tox, please install tox 2.9.1 or later > make: *** [tox] Error 1 > + teardown > + res=2 > + '[' 2 -ne 0 ']' > + echo '*** err: 2' > *** err: 2 > + collect_logs > + tar --directory /var/log --exclude 'journal/*' -czf > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/mock_varlogs.tar.gz > . > + tar --directory /var/host_log --exclude 'journal/*' -czf > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/host_varlogs.tar.gz > . > + teardown_storage > + python2 tests/storage/userstorage.py teardown > Can someone look at it? > Thank you in advance! > Pavel -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100107)

1 0

[CQ]: 102081, 24 (ovirt-engine-ui-extensions) failed "ovirt-4.3" system tests
by oVirt Jenkins 26 Aug '19

26 Aug '19

Change 102081,24 (ovirt-engine-ui-extensions) is probably the reason behind recent system test failures in the "ovirt-4.3" 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/102081/24 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.3_change-queue-tester/1900/

1 0

[CQ]: 102457, 15 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 26 Aug '19

26 Aug '19

A system test invoked by the "ovirt-master" change queue including change 102457,15 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/102457/15 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15514/

1 0

[CQ]: 102715,3 (mom) failed "ovirt-master" system tests
by oVirt Jenkins 26 Aug '19

26 Aug '19

Change 102715,3 (mom) 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/102715/3 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15510/

1 0

[CQ]: 101915, 18 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 26 Aug '19

26 Aug '19

A system test invoked by the "ovirt-master" change queue including change 101915,18 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/101915/18 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15507/

1 0

oVirt infra daily report - unstable production jobs - 928
by jenkins＠jenkins.phx.ovirt.org 26 Aug '19

26 Aug '19

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/928//artifact/exported-a… Cheers, Jenkins

1 0

[JIRA] (OVIRT-2783) CI fails - tox error
by Nir Soffer (oVirt JIRA) 25 Aug '19

25 Aug '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2783?page=com.atlassian.jira.… ] Nir Soffer commented on OVIRT-2783: ----------------------------------- On Sun, Aug 25, 2019, 15:19 Pavel Bar <pbar(a)redhat.com> wrote: > Hi, > We experience problems with failed CI on VDSM patches. > Does it work locally and in travis? Examples: > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10633/ > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10634/ > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10635/ > > This is what we see in logs: > > out=`tox --version`; \ > if [ $? -ne 0 ]; then \ > echo "Error: cannot run tox, please install tox \ > 2.9.1 or later"; \ > exit 1; \ > fi; \ > version=`echo $out | cut -d' ' -f1`; \ > if python2.7 build-aux/vercmp $version 2.9.1; then \ > echo "Error: tox is too old, please install tox \ > 2.9.1 or later"; \ > exit 1; \ > fi > Traceback (most recent call last): > File "/usr/bin/tox", line 7, in <module> > from tox import cmdline > File "/usr/lib/python2.7/site-packages/tox/__init__.py", line 4, in > <module> > from .hookspecs import hookimpl > File "/usr/lib/python2.7/site-packages/tox/hookspecs.py", line 4, in > <module> > from pluggy import HookimplMarker > File "/usr/lib/python2.7/site-packages/pluggy/__init__.py", line 16, in > <module> > from .manager import PluginManager, PluginValidationError > File "/usr/lib/python2.7/site-packages/pluggy/manager.py", line 6, in > <module> > import importlib_metadata > File "/usr/lib/python2.7/site-packages/importlib_metadata/__init__.py", > line 9, in <module> > import zipp > File "/usr/lib/python2.7/site-packages/zipp.py", line 12, in <module> > import more_itertools > File "/usr/lib/python2.7/site-packages/more_itertools/__init__.py", line > 1, in <module> > from more_itertools.more import * # noqa > File "/usr/lib/python2.7/site-packages/more_itertools/more.py", line 340 > def _collate(*iterables, key=lambda a: a, reverse=False): > ^ > SyntaxError: invalid syntax > Error: cannot run tox, please install tox 2.9.1 or later > make: *** [tox] Error 1 > + teardown > + res=2 > + '[' 2 -ne 0 ']' > + echo '*** err: 2' > *** err: 2 > + collect_logs > + tar --directory /var/log --exclude 'journal/*' -czf > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/mock_varlogs.tar.gz > . > + tar --directory /var/host_log --exclude 'journal/*' -czf > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/host_varlogs.tar.gz > . > + teardown_storage > + python2 tests/storage/userstorage.py teardown > > Can someone look at it? > > Thank you in advance! > > Pavel > > _______________________________________________ > Devel mailing list -- devel(a)ovirt.org > To unsubscribe send an email to devel-leave(a)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/VADZM35IRVN4E… > > CI fails - tox error > -------------------- > > Key: OVIRT-2783 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2783 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Pavel Bar > Assignee: infra > > Hi, > We experience problems with failed CI on VDSM patches. > Examples: > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10633/ > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10634/ > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10635/ > This is what we see in logs: > out=`tox --version`; \ > if [ $? -ne 0 ]; then \ > echo "Error: cannot run tox, please install tox \ > 2.9.1 or later"; \ > exit 1; \ > fi; \ > version=`echo $out | cut -d' ' -f1`; \ > if python2.7 build-aux/vercmp $version 2.9.1; then \ > echo "Error: tox is too old, please install tox \ > 2.9.1 or later"; \ > exit 1; \ > fi > Traceback (most recent call last): > File "/usr/bin/tox", line 7, in <module> > from tox import cmdline > File "/usr/lib/python2.7/site-packages/tox/__init__.py", line 4, in > <module> > from .hookspecs import hookimpl > File "/usr/lib/python2.7/site-packages/tox/hookspecs.py", line 4, in > <module> > from pluggy import HookimplMarker > File "/usr/lib/python2.7/site-packages/pluggy/__init__.py", line 16, in > <module> > from .manager import PluginManager, PluginValidationError > File "/usr/lib/python2.7/site-packages/pluggy/manager.py", line 6, in > <module> > import importlib_metadata > File "/usr/lib/python2.7/site-packages/importlib_metadata/__init__.py", > line 9, in <module> > import zipp > File "/usr/lib/python2.7/site-packages/zipp.py", line 12, in <module> > import more_itertools > File "/usr/lib/python2.7/site-packages/more_itertools/__init__.py", line > 1, in <module> > from more_itertools.more import * # noqa > File "/usr/lib/python2.7/site-packages/more_itertools/more.py", line 340 > def _collate(*iterables, key=lambda a: a, reverse=False): > ^ > SyntaxError: invalid syntax > Error: cannot run tox, please install tox 2.9.1 or later > make: *** [tox] Error 1 > + teardown > + res=2 > + '[' 2 -ne 0 ']' > + echo '*** err: 2' > *** err: 2 > + collect_logs > + tar --directory /var/log --exclude 'journal/*' -czf > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/mock_varlogs.tar.gz > . > + tar --directory /var/host_log --exclude 'journal/*' -czf > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/host_varlogs.tar.gz > . > + teardown_storage > + python2 tests/storage/userstorage.py teardown > Can someone look at it? > Thank you in advance! > Pavel -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100107)

1 0

[CQ]: 102129, 13 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 25 Aug '19

25 Aug '19

A system test invoked by the "ovirt-master" change queue including change 102129,13 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/102129/13 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15501/

1 0

[JIRA] (OVIRT-2783) CI fails - tox error
by Eyal Edri (oVirt JIRA) 25 Aug '19

25 Aug '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2783?page=com.atlassian.jira.… ] Eyal Edri commented on OVIRT-2783: ---------------------------------- It looks like a syntax error, before it can’t install tox: File "/usr/lib/python2.7/site-packages/more_itertools/more.py", line 340def _collate(*iterables, key=lambda a: a, reverse=False):^SyntaxError: invalid syntax > CI fails - tox error > -------------------- > > Key: OVIRT-2783 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2783 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Pavel Bar > Assignee: infra > > Hi, > We experience problems with failed CI on VDSM patches. > Examples: > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10633/ > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10634/ > http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10635/ > This is what we see in logs: > out=`tox --version`; \ > if [ $? -ne 0 ]; then \ > echo "Error: cannot run tox, please install tox \ > 2.9.1 or later"; \ > exit 1; \ > fi; \ > version=`echo $out | cut -d' ' -f1`; \ > if python2.7 build-aux/vercmp $version 2.9.1; then \ > echo "Error: tox is too old, please install tox \ > 2.9.1 or later"; \ > exit 1; \ > fi > Traceback (most recent call last): > File "/usr/bin/tox", line 7, in <module> > from tox import cmdline > File "/usr/lib/python2.7/site-packages/tox/__init__.py", line 4, in > <module> > from .hookspecs import hookimpl > File "/usr/lib/python2.7/site-packages/tox/hookspecs.py", line 4, in > <module> > from pluggy import HookimplMarker > File "/usr/lib/python2.7/site-packages/pluggy/__init__.py", line 16, in > <module> > from .manager import PluginManager, PluginValidationError > File "/usr/lib/python2.7/site-packages/pluggy/manager.py", line 6, in > <module> > import importlib_metadata > File "/usr/lib/python2.7/site-packages/importlib_metadata/__init__.py", > line 9, in <module> > import zipp > File "/usr/lib/python2.7/site-packages/zipp.py", line 12, in <module> > import more_itertools > File "/usr/lib/python2.7/site-packages/more_itertools/__init__.py", line > 1, in <module> > from more_itertools.more import * # noqa > File "/usr/lib/python2.7/site-packages/more_itertools/more.py", line 340 > def _collate(*iterables, key=lambda a: a, reverse=False): > ^ > SyntaxError: invalid syntax > Error: cannot run tox, please install tox 2.9.1 or later > make: *** [tox] Error 1 > + teardown > + res=2 > + '[' 2 -ne 0 ']' > + echo '*** err: 2' > *** err: 2 > + collect_logs > + tar --directory /var/log --exclude 'journal/*' -czf > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/mock_varlogs.tar.gz > . > + tar --directory /var/host_log --exclude 'journal/*' -czf > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/host_varlogs.tar.gz > . > + teardown_storage > + python2 tests/storage/userstorage.py teardown > Can someone look at it? > Thank you in advance! > Pavel -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100107)

1 0

[CQ]: 101914, 12 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 25 Aug '19

25 Aug '19

A system test invoked by the "ovirt-master" change queue including change 101914,12 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/101914/12 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15500/

1 0

[JIRA] (OVIRT-2783) CI fails - tox error
by Pavel Bar (oVirt JIRA) 25 Aug '19

25 Aug '19

Pavel Bar created OVIRT-2783: -------------------------------- Summary: CI fails - tox error Key: OVIRT-2783 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2783 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Pavel Bar Assignee: infra Hi, We experience problems with failed CI on VDSM patches. Examples: http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10633/ http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10634/ http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10635/ This is what we see in logs: out=`tox --version`; \ if [ $? -ne 0 ]; then \ echo "Error: cannot run tox, please install tox \ 2.9.1 or later"; \ exit 1; \ fi; \ version=`echo $out | cut -d' ' -f1`; \ if python2.7 build-aux/vercmp $version 2.9.1; then \ echo "Error: tox is too old, please install tox \ 2.9.1 or later"; \ exit 1; \ fi Traceback (most recent call last): File "/usr/bin/tox", line 7, in <module> from tox import cmdline File "/usr/lib/python2.7/site-packages/tox/__init__.py", line 4, in <module> from .hookspecs import hookimpl File "/usr/lib/python2.7/site-packages/tox/hookspecs.py", line 4, in <module> from pluggy import HookimplMarker File "/usr/lib/python2.7/site-packages/pluggy/__init__.py", line 16, in <module> from .manager import PluginManager, PluginValidationError File "/usr/lib/python2.7/site-packages/pluggy/manager.py", line 6, in <module> import importlib_metadata File "/usr/lib/python2.7/site-packages/importlib_metadata/__init__.py", line 9, in <module> import zipp File "/usr/lib/python2.7/site-packages/zipp.py", line 12, in <module> import more_itertools File "/usr/lib/python2.7/site-packages/more_itertools/__init__.py", line 1, in <module> from more_itertools.more import * # noqa File "/usr/lib/python2.7/site-packages/more_itertools/more.py", line 340 def _collate(*iterables, key=lambda a: a, reverse=False): ^ SyntaxError: invalid syntax Error: cannot run tox, please install tox 2.9.1 or later make: *** [tox] Error 1 + teardown + res=2 + '[' 2 -ne 0 ']' + echo '*** err: 2' *** err: 2 + collect_logs + tar --directory /var/log --exclude 'journal/*' -czf /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/mock_varlogs.tar.gz . + tar --directory /var/host_log --exclude 'journal/*' -czf /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/host_varlogs.tar.gz . + teardown_storage + python2 tests/storage/userstorage.py teardown Can someone look at it? Thank you in advance! Pavel -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100107)

1 0

[CQ]: 102693, 2 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 25 Aug '19

25 Aug '19

A system test invoked by the "ovirt-master" change queue including change 102693,2 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/102693/2 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15499/

1 0

[oVirt] [CQ weekly status] [25-08-2019]
by Dusan Fodor 25 Aug '19

25 Aug '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.2*: GREEN (#2) Last failure was on 20-08 for ovirt-ansible-hosted-engine-setup. It was caused by random network issue (fetching repo from github), retriggered job for the change passed well. *CQ-4.3*: GREEN (#2) Last failure was on 20-08 for ovirt-ansible-hosted-engine-setup. It was caused by random network issue, retriggered job for the change passed well. *CQ-Master:* RED (#1) Last failure was on 25-08 for ovirt-engine, caused by failed cloning of engine repo (even with lately increased timeout value 20min). Related ticket from last time was reopened. Current running jobs for 4.2 [1], 4.3 [2] and master [3] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -4.2_change-queue-tester/ [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -4.3_change-queue-tester/ [3] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -master_change-queue-tester/ Have a nice week! Dusan ------------------------------------------------------------------------------------------------------------------- COLOUR MAP Green = job has been passing successfully ** green for more than 3 days may suggest we need a review of our test coverage 1. 1-3 days GREEN (#1) 2. 4-7 days GREEN (#2) 3. Over 7 days GREEN (#3) Yellow = intermittent failures for different projects but no lasting or current regressions ** intermittent would be a healthy project as we expect a number of failures during the week ** I will not report any of the solved failures or regressions. 1. Solved job failures YELLOW (#1) 2. Solved regressions YELLOW (#2) Red = job has been failing ** Active Failures. The colour will change based on the amount of time the project/s has been broken. Only active regressions would be reported. 1. 1-3 days RED (#1) 2. 4-7 days RED (#2) 3. Over 7 days RED (#3) _______________________________________________ Devel mailing list -- devel(a)ovirt.org To unsubscribe send an email to devel-leave(a)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/YCNCKRK3G4EJXA3OCYAUS4VMKRDA67F4/

1 0

[JIRA] (OVIRT-2782) Configure Jenkins to wait less and allocate more
by Daniel Belenky (oVirt JIRA) 25 Aug '19

25 Aug '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2782?page=com.atlassian.jira.… ] Daniel Belenky updated OVIRT-2782: ---------------------------------- Description: By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting {code:java} hudson.slaves.NodeProvisioner.initialDelay=0 {code} We can also control the excessive workload threshold and force Jenkins to allocate slaves for jobs in the queue... but, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we set it's margins to higher values and it effectively lowers its threshold so that Jenkins will allocate nodes faster and in advance. The recommended settings by the k8s plugin to spawn a node for every build in the queue: {code:java} -Dhudson.slaves.NodeProvisioner.initialDelay=0 -Dhudson.slaves.NodeProvisioner.MARGIN=50 -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85 {code} was: By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting {code:java} hudson.slaves.NodeProvisioner.initialDelay=0 {code} We can also control the excessive workload threshold and force Jenkins to allocate slaves for jobs in the queue... but, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we set it's margins to higher values and it effectively lowers its threshold so that Jenkins will allocate nodes faster and in advance. The recommended settings by the k8s plugin to spawn a node for every build in the queue: ``` By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting `hudson.slaves.NodeProvisioner.initialDelay` to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can lower its threshold so that Jenkins will allocate nodes faster and in advance. {code:java} -Dhudson.slaves.NodeProvisioner.initialDelay=0 -Dhudson.slaves.NodeProvisioner.MARGIN=50 -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85 {code} > Configure Jenkins to wait less and allocate more > ------------------------------------------------ > > Key: OVIRT-2782 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2782 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Daniel Belenky > Assignee: infra > > By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting > {code:java} > hudson.slaves.NodeProvisioner.initialDelay=0 > {code} > We can also control the excessive workload threshold and force Jenkins to allocate slaves for jobs in the queue... but, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we set it's margins to higher values and it effectively lowers its threshold so that Jenkins will allocate nodes faster and in advance. > The recommended settings by the k8s plugin to spawn a node for every build in the queue: > {code:java} > -Dhudson.slaves.NodeProvisioner.initialDelay=0 > -Dhudson.slaves.NodeProvisioner.MARGIN=50 > -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85 > {code} -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100107)

1 0

[JIRA] (OVIRT-2782) Configure Jenkins to wait less and allocate more
by Daniel Belenky (oVirt JIRA) 25 Aug '19

25 Aug '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2782?page=com.atlassian.jira.… ] Daniel Belenky updated OVIRT-2782: ---------------------------------- Description: By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting {code:java} hudson.slaves.NodeProvisioner.initialDelay=0 {code} We can also control the excessive workload threshold and force Jenkins to allocate slaves for jobs in the queue... but, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we set it's margins to higher values and it effectively lowers its threshold so that Jenkins will allocate nodes faster and in advance. The recommended settings by the k8s plugin to spawn a node for every build in the queue: ``` By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting `hudson.slaves.NodeProvisioner.initialDelay` to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can lower its threshold so that Jenkins will allocate nodes faster and in advance. {code:java} -Dhudson.slaves.NodeProvisioner.initialDelay=0 -Dhudson.slaves.NodeProvisioner.MARGIN=50 -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85 {code} was: By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting {code:java} hudson.slaves.NodeProvisioner.initialDelay=0 {code} But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can control it's margins to lower its threshold so that Jenkins will allocate nodes faster and in advance. The recommended settings by the k8s plugin to spawn a node for every build in the queue: ``` By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting `hudson.slaves.NodeProvisioner.initialDelay` to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can lower its threshold so that Jenkins will allocate nodes faster and in advance. {code:java} -Dhudson.slaves.NodeProvisioner.initialDelay=0 -Dhudson.slaves.NodeProvisioner.MARGIN=50 -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85 {code} > Configure Jenkins to wait less and allocate more > ------------------------------------------------ > > Key: OVIRT-2782 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2782 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Daniel Belenky > Assignee: infra > > By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting > {code:java} > hudson.slaves.NodeProvisioner.initialDelay=0 > {code} > We can also control the excessive workload threshold and force Jenkins to allocate slaves for jobs in the queue... but, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we set it's margins to higher values and it effectively lowers its threshold so that Jenkins will allocate nodes faster and in advance. > The recommended settings by the k8s plugin to spawn a node for every build in the queue: > ``` > By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting `hudson.slaves.NodeProvisioner.initialDelay` to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can lower its threshold so that Jenkins will allocate nodes faster and in advance. > {code:java} > -Dhudson.slaves.NodeProvisioner.initialDelay=0 > -Dhudson.slaves.NodeProvisioner.MARGIN=50 > -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85 > {code} -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100107)

1 0

[JIRA] (OVIRT-2782) Configure Jenkins to wait less and allocate more
by Daniel Belenky (oVirt JIRA) 25 Aug '19

25 Aug '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2782?page=com.atlassian.jira.… ] Daniel Belenky updated OVIRT-2782: ---------------------------------- Description: By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting {code:java} hudson.slaves.NodeProvisioner.initialDelay=0 {code} But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can control it's margins to lower its threshold so that Jenkins will allocate nodes faster and in advance. The recommended settings by the k8s plugin to spawn a node for every build in the queue: ``` By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting `hudson.slaves.NodeProvisioner.initialDelay` to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can lower its threshold so that Jenkins will allocate nodes faster and in advance. {code:java} -Dhudson.slaves.NodeProvisioner.initialDelay=0 -Dhudson.slaves.NodeProvisioner.MARGIN=50 -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85 {code} was: By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting {code:java} hudson.slaves.NodeProvisioner.initialDelay {code} to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can control it's margins to lower its threshold so that Jenkins will allocate nodes faster and in advance. The recommended settings by the k8s plugin to spawn a node for every build in the queue: ``` By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting `hudson.slaves.NodeProvisioner.initialDelay` to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can lower its threshold so that Jenkins will allocate nodes faster and in advance. {code:java} -Dhudson.slaves.NodeProvisioner.initialDelay=0 -Dhudson.slaves.NodeProvisioner.MARGIN=50 -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85 {code} > Configure Jenkins to wait less and allocate more > ------------------------------------------------ > > Key: OVIRT-2782 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2782 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Daniel Belenky > Assignee: infra > > By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting > {code:java} > hudson.slaves.NodeProvisioner.initialDelay=0 > {code} > But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can control it's margins to lower its threshold so that Jenkins will allocate nodes faster and in advance. > The recommended settings by the k8s plugin to spawn a node for every build in the queue: > ``` > By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting `hudson.slaves.NodeProvisioner.initialDelay` to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can lower its threshold so that Jenkins will allocate nodes faster and in advance. > {code:java} > -Dhudson.slaves.NodeProvisioner.initialDelay=0 > -Dhudson.slaves.NodeProvisioner.MARGIN=50 > -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85 > {code} -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100107)

1 0

[JIRA] (OVIRT-2782) Configure Jenkins to wait less and allocate more
by Daniel Belenky (oVirt JIRA) 25 Aug '19

25 Aug '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2782?page=com.atlassian.jira.… ] Daniel Belenky updated OVIRT-2782: ---------------------------------- Description: By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting {code:java} hudson.slaves.NodeProvisioner.initialDelay {code} to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can control it's margins to lower its threshold so that Jenkins will allocate nodes faster and in advance. The recommended settings by the k8s plugin to spawn a node for every build in the queue: ``` By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting `hudson.slaves.NodeProvisioner.initialDelay` to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can lower its threshold so that Jenkins will allocate nodes faster and in advance. {code:java} -Dhudson.slaves.NodeProvisioner.initialDelay=0 -Dhudson.slaves.NodeProvisioner.MARGIN=50 -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85 {code} was: By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting `hudson.slaves.NodeProvisioner.initialDelay` to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can control it's margins to lower its threshold so that Jenkins will allocate nodes faster and in advance. The recommended settings by the k8s plugin to spawn a node for every build in the queue: ``` By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting `hudson.slaves.NodeProvisioner.initialDelay` to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can lower its threshold so that Jenkins will allocate nodes faster and in advance. {code:java} -Dhudson.slaves.NodeProvisioner.initialDelay=0 -Dhudson.slaves.NodeProvisioner.MARGIN=50 -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85 {code} > Configure Jenkins to wait less and allocate more > ------------------------------------------------ > > Key: OVIRT-2782 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2782 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Daniel Belenky > Assignee: infra > > By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting > {code:java} > hudson.slaves.NodeProvisioner.initialDelay > {code} > to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can control it's margins to lower its threshold so that Jenkins will allocate nodes faster and in advance. > The recommended settings by the k8s plugin to spawn a node for every build in the queue: > ``` > By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting `hudson.slaves.NodeProvisioner.initialDelay` to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can lower its threshold so that Jenkins will allocate nodes faster and in advance. > {code:java} > -Dhudson.slaves.NodeProvisioner.initialDelay=0 > -Dhudson.slaves.NodeProvisioner.MARGIN=50 > -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85 > {code} -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100107)

1 0

[JIRA] (OVIRT-2782) Configure Jenkins to wait less and allocate more
by Daniel Belenky (oVirt JIRA) 25 Aug '19

25 Aug '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2782?page=com.atlassian.jira.… ] Daniel Belenky updated OVIRT-2782: ---------------------------------- Description: By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting `hudson.slaves.NodeProvisioner.initialDelay` to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can control it's margins to lower its threshold so that Jenkins will allocate nodes faster and in advance. The recommended settings by the k8s plugin to spawn a node for every build in the queue: ``` By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting `hudson.slaves.NodeProvisioner.initialDelay` to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can lower its threshold so that Jenkins will allocate nodes faster and in advance. {code:java} -Dhudson.slaves.NodeProvisioner.initialDelay=0 -Dhudson.slaves.NodeProvisioner.MARGIN=50 -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85 {code} was: By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting `hudson.slaves.NodeProvisioner.initialDelay` to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can control it's margins to lower its threshold so that Jenkins will allocate nodes faster and in advance. The recommended settings by the k8s plugin to spawn a node for every build in the queue: ``` By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting `hudson.slaves.NodeProvisioner.initialDelay` to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can lower its threshold so that Jenkins will allocate nodes faster and in advance. ``` -Dhudson.slaves.NodeProvisioner.initialDelay=0 -Dhudson.slaves.NodeProvisioner.MARGIN=50 -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85 ``` > Configure Jenkins to wait less and allocate more > ------------------------------------------------ > > Key: OVIRT-2782 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2782 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Daniel Belenky > Assignee: infra > > By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting `hudson.slaves.NodeProvisioner.initialDelay` to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can control it's margins to lower its threshold so that Jenkins will allocate nodes faster and in advance. > The recommended settings by the k8s plugin to spawn a node for every build in the queue: > ``` > By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting `hudson.slaves.NodeProvisioner.initialDelay` to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can lower its threshold so that Jenkins will allocate nodes faster and in advance. > {code:java} > -Dhudson.slaves.NodeProvisioner.initialDelay=0 > -Dhudson.slaves.NodeProvisioner.MARGIN=50 > -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85 > {code} -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100107)

1 0

[JIRA] (OVIRT-2782) Configure Jenkins to wait less and allocate more
by Daniel Belenky (oVirt JIRA) 25 Aug '19

25 Aug '19

Daniel Belenky created OVIRT-2782: ------------------------------------- Summary: Configure Jenkins to wait less and allocate more Key: OVIRT-2782 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2782 Project: oVirt - virtualization made easy Issue Type: Improvement Reporter: Daniel Belenky Assignee: infra By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting `hudson.slaves.NodeProvisioner.initialDelay` to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can control it's margins to lower its threshold so that Jenkins will allocate nodes faster and in advance. The recommended settings by the k8s plugin to spawn a node for every build in the queue: ``` By default, Jenkins is configured to wait a few seconds before allocating a new node in a hope that a node in use to be freed. We can control this setting by setting `hudson.slaves.NodeProvisioner.initialDelay` to `0`. But, because Jenkins computes the excess workload value (which decides if we need to allocate a new node) using an EMA, we also can lower its threshold so that Jenkins will allocate nodes faster and in advance. ``` -Dhudson.slaves.NodeProvisioner.initialDelay=0 -Dhudson.slaves.NodeProvisioner.MARGIN=50 -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85 ``` -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100107)

1 0

oVirt infra daily report - unstable production jobs - 927
by jenkins＠jenkins.phx.ovirt.org 25 Aug '19

25 Aug '19

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/927//artifact/exported-a… Cheers, Jenkins

1 0

oVirt infra daily report - unstable production jobs - 926
by jenkins＠jenkins.phx.ovirt.org 24 Aug '19

24 Aug '19

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/926//artifact/exported-a… Cheers, Jenkins

1 0

[CQ]: 101914, 12 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 23 Aug '19

23 Aug '19

A system test invoked by the "ovirt-master" change queue including change 101914,12 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 101913,10 (ovirt-engine) 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 101913,10 (ovirt-engine) 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/101914/12 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15492/

1 0

[CQ]: 101913,10 (ovirt-engine) failed "ovirt-master" system tests
by oVirt Jenkins 23 Aug '19

23 Aug '19

Change 101913,10 (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/101913/10 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15490/

1 0

oVirt infra daily report - unstable production jobs - 925
by jenkins＠jenkins.phx.ovirt.org 23 Aug '19

23 Aug '19

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/925//artifact/exported-a… Cheers, Jenkins

1 0