- Infra - oVirt List Archives

[JIRA] (OVIRT-1536) Documentation about the change-queue flow
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1536?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1536: -------------------------------- Epic Link: (was: OVIRT-400) > Documentation about the change-queue flow > ----------------------------------------- > > Key: OVIRT-1536 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1536 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > Labels: change-queue > > Add some reference documentation about the change-queue flow. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1549) run OST as a third-party tester for OpenStack's ovsdbapp
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1549?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1549: -------------------------------- Epic Link: (was: OVIRT-400) > run OST as a third-party tester for OpenStack's ovsdbapp > -------------------------------------------------------- > > Key: OVIRT-1549 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1549 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: danken > Assignee: infra > > https://github.com/openstack/ovsdbapp is a python binding for openvswitch-ovn. ovirt-provider-ovn is planning to use it instead of its own implementation. > ovsdbapp developers want to make sure they do not break the ovirt use case. I would like us to follow https://docs.openstack.org/infra/system-config/third_party.html and become a third-party tester of ovsdbapp. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1549) run OST as a third-party tester for OpenStack's ovsdbapp
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1549?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1549: -------------------------------- Epic Link: (was: OVIRT-400) > run OST as a third-party tester for OpenStack's ovsdbapp > -------------------------------------------------------- > > Key: OVIRT-1549 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1549 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: danken > Assignee: infra > > https://github.com/openstack/ovsdbapp is a python binding for openvswitch-ovn. ovirt-provider-ovn is planning to use it instead of its own implementation. > ovsdbapp developers want to make sure they do not break the ovirt use case. I would like us to follow https://docs.openstack.org/infra/system-config/third_party.html and become a third-party tester of ovsdbapp. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1554) Get rid of old 'create_rpms' jobs
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1554?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1554: -------------------------------- Epic Link: (was: OVIRT-400) > Get rid of old 'create_rpms' jobs > --------------------------------- > > Key: OVIRT-1554 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1554 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > Labels: re-factor, standard-ci > > '*create_rpms*' jobs are the old kind of jobs that we used to have before STD-CI. We still have many of those laying around. > Here is the list for the time of writing these lines: > # vdsm_any_create-rpms_manual > # mom_any_create-rpms_manual_old > # qemu_4.1_create-rpms-el7-x86_64_merged > # qemu_4.1_create-rpms-el7-ppc64le_merged > # qemu_4.1_create-rpms-el7-x86_64_created > # qemu_4.1_create-rpms-el7-ppc64le_created > # qemu_master_create-rpms-el7-x86_64_created > # slf4j_master_create-rpms-el6-x86_64_merged > # qemu_master_create-rpms-el7-ppc64le_created > # slf4j_master_create-rpms-el6-x86_64_created > # ioprocess_0.15_create-rpms-el7-x86_64_merged > # ovirt-wgt_4.1_create-rpms-fc24-x86_64_merged > # ioprocess_0.15_create-rpms-el7-x86_64_created > # ovirt-wgt_4.1_create-rpms-fc24-x86_64_created > # ovirt-reports_3.6_create-rpms-el6-x86_64_merged > # ovirt-reports_3.6_create-rpms-el7-x86_64_merged > # ovirt-wgt_master_create-rpms-fc25-x86_64_merged > # py2exe-py2.7_4.1_create-rpms-fc24-x86_64_merged > # pywin32-py2.7_4.1_create-rpms-el7-x86_64_merged > # vcredist-x86_4.1_create-rpms-fc24-x86_64_merged > # ovirt-reports_3.6_create-rpms-el6-x86_64_created > # ovirt-reports_3.6_create-rpms-el7-x86_64_created > # ovirt-wgt_master_create-rpms-fc25-x86_64_created > # py2exe-py2.7_4.1_create-rpms-fc24-x86_64_created > # python-windows_4.1_create-rpms-el7-x86_64_merged > # pywin32-py2.7_4.1_create-rpms-el7-x86_64_created > # pywin32-py2.7_4.1_create-rpms-fc24-x86_64_merged > # vcredist-x86_4.1_create-rpms-fc24-x86_64_created > # ovirt-hosted-engine-ha_any_create-rpms_manual_old > # ovirt-vmconsole_3.6_create-rpms-el6-x86_64_merged > # ovirt-vmconsole_3.6_create-rpms-el7-x86_64_merged > # python-windows_4.1_create-rpms-el7-x86_64_created > # python-windows_4.1_create-rpms-fc24-x86_64_merged > # pywin32-py2.7_4.1_create-rpms-fc24-x86_64_created > # ovirt-vmconsole_3.6_create-rpms-el6-x86_64_created > # ovirt-vmconsole_3.6_create-rpms-el7-x86_64_created > # py2exe-py2.7_master_create-rpms-fc25-x86_64_merged > # python-windows_4.1_create-rpms-fc24-x86_64_created > # pywin32-py2.7_master_create-rpms-el7-x86_64_merged > # vcredist-x86_master_create-rpms-fc25-x86_64_merged > # vcredist-x86_master_create-rpms-fc26-x86_64_merged > # ovirt-host-deploy_3.6_create-rpms-el6-x86_64_merged > # ovirt-host-deploy_3.6_create-rpms-el7-x86_64_merged > # py2exe-py2.7_master_create-rpms-fc25-x86_64_created > # python-windows_master_create-rpms-el7-x86_64_merged > # pywin32-py2.7_master_create-rpms-el7-x86_64_created > # pywin32-py2.7_master_create-rpms-fc25-x86_64_merged > # pywin32-py2.7_master_create-rpms-fc26-x86_64_merged > # vcredist-x86_master_create-rpms-fc25-x86_64_created > # vcredist-x86_master_create-rpms-fc26-x86_64_created > # ovirt-host-deploy_3.6_create-rpms-el6-x86_64_created > # ovirt-host-deploy_3.6_create-rpms-el7-x86_64_created > # python-windows_master_create-rpms-el7-x86_64_created > # python-windows_master_create-rpms-fc25-x86_64_merged > # python-windows_master_create-rpms-fc26-x86_64_merged > # pywin32-py2.7_master_create-rpms-fc25-x86_64_created > # pywin32-py2.7_master_create-rpms-fc26-x86_64_created > # ovirt-log-collector_3.6_create-rpms-el6-x86_64_merged > # ovirt-log-collector_3.6_create-rpms-el7-x86_64_merged > # python-windows_master_create-rpms-fc25-x86_64_created > # python-windows_master_create-rpms-fc26-x86_64_created > # ovirt-log-collector_3.6_create-rpms-el6-x86_64_created > # ovirt-log-collector_3.6_create-rpms-el7-x86_64_created > # ovirt-engine-sdk-java_3.6_create-rpms-el6-x86_64_merged > # ovirt-engine-sdk-java_3.6_create-rpms-el7-x86_64_merged > # ovirt-engine-sdk-java_3.6_create-rpms-fc24-x86_64_merged > # ovirt-engine-wildfly10_4.1_create-rpms-el7-x86_64_merged > # ovirt-hosted-engine-ha_3.6_create-rpms-el7-x86_64_merged > # jasperreports-server_master_create-rpms-el6-x86_64_merged > # jasperreports-server_master_create-rpms-el7-x86_64_merged > # ovirt-engine-wildfly10_4.1_create-rpms-el7-x86_64_created > # ovirt-engine-wildfly10_4.1_create-rpms-fc24-x86_64_merged > # ovirt-hosted-engine-ha_3.6_create-rpms-el7-x86_64_created > # jasperreports-server_master_create-rpms-el6-x86_64_created > # jasperreports-server_master_create-rpms-el7-x86_64_created > # ovirt-engine-wildfly10_4.1_create-rpms-fc24-x86_64_created > # ovirt-engine-wildfly10_master_create-rpms-el7-x86_64_merged > # ovirt-engine-wildfly10_master_create-rpms-el7-x86_64_created > # ovirt-engine-wildfly10_master_create-rpms-fc25-x86_64_merged > # ovirt-engine-wildfly10_master_create-rpms-fc26-x86_64_merged > # nsis-simple-service-plugin_4.1_create-rpms-fc24-x86_64_merged > # ovirt-engine-wildfly10_master_create-rpms-fc25-x86_64_created > # ovirt-engine-wildfly10_master_create-rpms-fc26-x86_64_created > # nsis-simple-service-plugin_4.1_create-rpms-fc24-x86_64_created > # tmp_ovirt-hosted-engine-ha_master_create-rpms-el7-x86_64_tagged > # nsis-simple-service-plugin_master_create-rpms-fc25-x86_64_merged > # ovirt-engine-wildfly-overlay10_4.1_create-rpms-el6-x86_64_merged > # ovirt-engine-wildfly-overlay10_4.1_create-rpms-el7-x86_64_merged > # nsis-simple-service-plugin_master_create-rpms-fc25-x86_64_created > # ovirt-engine-wildfly-overlay10_4.1_create-rpms-el6-x86_64_created > # ovirt-engine-wildfly-overlay10_4.1_create-rpms-el7-x86_64_created > # ovirt-engine-wildfly-overlay10_4.1_create-rpms-fc24-x86_64_merged > # ovirt-engine-wildfly-overlay10_4.1_create-rpms-fc24-x86_64_created > # ovirt-engine-wildfly-overlay10_master_create-rpms-el6-x86_64_merged > # ovirt-engine-wildfly-overlay10_master_create-rpms-el7-x86_64_merged > # ovirt-engine-wildfly-overlay10_master_create-rpms-el6-x86_64_created > # ovirt-engine-wildfly-overlay10_master_create-rpms-el7-x86_64_created > # ovirt-engine-wildfly-overlay10_master_create-rpms-fc25-x86_64_merged > # ovirt-engine-wildfly-overlay10_master_create-rpms-fc25-x86_64_created -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1554) Get rid of old 'create_rpms' jobs
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1554?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1554: -------------------------------- Epic Link: (was: OVIRT-400) > Get rid of old 'create_rpms' jobs > --------------------------------- > > Key: OVIRT-1554 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1554 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > Labels: re-factor, standard-ci > > '*create_rpms*' jobs are the old kind of jobs that we used to have before STD-CI. We still have many of those laying around. > Here is the list for the time of writing these lines: > # vdsm_any_create-rpms_manual > # mom_any_create-rpms_manual_old > # qemu_4.1_create-rpms-el7-x86_64_merged > # qemu_4.1_create-rpms-el7-ppc64le_merged > # qemu_4.1_create-rpms-el7-x86_64_created > # qemu_4.1_create-rpms-el7-ppc64le_created > # qemu_master_create-rpms-el7-x86_64_created > # slf4j_master_create-rpms-el6-x86_64_merged > # qemu_master_create-rpms-el7-ppc64le_created > # slf4j_master_create-rpms-el6-x86_64_created > # ioprocess_0.15_create-rpms-el7-x86_64_merged > # ovirt-wgt_4.1_create-rpms-fc24-x86_64_merged > # ioprocess_0.15_create-rpms-el7-x86_64_created > # ovirt-wgt_4.1_create-rpms-fc24-x86_64_created > # ovirt-reports_3.6_create-rpms-el6-x86_64_merged > # ovirt-reports_3.6_create-rpms-el7-x86_64_merged > # ovirt-wgt_master_create-rpms-fc25-x86_64_merged > # py2exe-py2.7_4.1_create-rpms-fc24-x86_64_merged > # pywin32-py2.7_4.1_create-rpms-el7-x86_64_merged > # vcredist-x86_4.1_create-rpms-fc24-x86_64_merged > # ovirt-reports_3.6_create-rpms-el6-x86_64_created > # ovirt-reports_3.6_create-rpms-el7-x86_64_created > # ovirt-wgt_master_create-rpms-fc25-x86_64_created > # py2exe-py2.7_4.1_create-rpms-fc24-x86_64_created > # python-windows_4.1_create-rpms-el7-x86_64_merged > # pywin32-py2.7_4.1_create-rpms-el7-x86_64_created > # pywin32-py2.7_4.1_create-rpms-fc24-x86_64_merged > # vcredist-x86_4.1_create-rpms-fc24-x86_64_created > # ovirt-hosted-engine-ha_any_create-rpms_manual_old > # ovirt-vmconsole_3.6_create-rpms-el6-x86_64_merged > # ovirt-vmconsole_3.6_create-rpms-el7-x86_64_merged > # python-windows_4.1_create-rpms-el7-x86_64_created > # python-windows_4.1_create-rpms-fc24-x86_64_merged > # pywin32-py2.7_4.1_create-rpms-fc24-x86_64_created > # ovirt-vmconsole_3.6_create-rpms-el6-x86_64_created > # ovirt-vmconsole_3.6_create-rpms-el7-x86_64_created > # py2exe-py2.7_master_create-rpms-fc25-x86_64_merged > # python-windows_4.1_create-rpms-fc24-x86_64_created > # pywin32-py2.7_master_create-rpms-el7-x86_64_merged > # vcredist-x86_master_create-rpms-fc25-x86_64_merged > # vcredist-x86_master_create-rpms-fc26-x86_64_merged > # ovirt-host-deploy_3.6_create-rpms-el6-x86_64_merged > # ovirt-host-deploy_3.6_create-rpms-el7-x86_64_merged > # py2exe-py2.7_master_create-rpms-fc25-x86_64_created > # python-windows_master_create-rpms-el7-x86_64_merged > # pywin32-py2.7_master_create-rpms-el7-x86_64_created > # pywin32-py2.7_master_create-rpms-fc25-x86_64_merged > # pywin32-py2.7_master_create-rpms-fc26-x86_64_merged > # vcredist-x86_master_create-rpms-fc25-x86_64_created > # vcredist-x86_master_create-rpms-fc26-x86_64_created > # ovirt-host-deploy_3.6_create-rpms-el6-x86_64_created > # ovirt-host-deploy_3.6_create-rpms-el7-x86_64_created > # python-windows_master_create-rpms-el7-x86_64_created > # python-windows_master_create-rpms-fc25-x86_64_merged > # python-windows_master_create-rpms-fc26-x86_64_merged > # pywin32-py2.7_master_create-rpms-fc25-x86_64_created > # pywin32-py2.7_master_create-rpms-fc26-x86_64_created > # ovirt-log-collector_3.6_create-rpms-el6-x86_64_merged > # ovirt-log-collector_3.6_create-rpms-el7-x86_64_merged > # python-windows_master_create-rpms-fc25-x86_64_created > # python-windows_master_create-rpms-fc26-x86_64_created > # ovirt-log-collector_3.6_create-rpms-el6-x86_64_created > # ovirt-log-collector_3.6_create-rpms-el7-x86_64_created > # ovirt-engine-sdk-java_3.6_create-rpms-el6-x86_64_merged > # ovirt-engine-sdk-java_3.6_create-rpms-el7-x86_64_merged > # ovirt-engine-sdk-java_3.6_create-rpms-fc24-x86_64_merged > # ovirt-engine-wildfly10_4.1_create-rpms-el7-x86_64_merged > # ovirt-hosted-engine-ha_3.6_create-rpms-el7-x86_64_merged > # jasperreports-server_master_create-rpms-el6-x86_64_merged > # jasperreports-server_master_create-rpms-el7-x86_64_merged > # ovirt-engine-wildfly10_4.1_create-rpms-el7-x86_64_created > # ovirt-engine-wildfly10_4.1_create-rpms-fc24-x86_64_merged > # ovirt-hosted-engine-ha_3.6_create-rpms-el7-x86_64_created > # jasperreports-server_master_create-rpms-el6-x86_64_created > # jasperreports-server_master_create-rpms-el7-x86_64_created > # ovirt-engine-wildfly10_4.1_create-rpms-fc24-x86_64_created > # ovirt-engine-wildfly10_master_create-rpms-el7-x86_64_merged > # ovirt-engine-wildfly10_master_create-rpms-el7-x86_64_created > # ovirt-engine-wildfly10_master_create-rpms-fc25-x86_64_merged > # ovirt-engine-wildfly10_master_create-rpms-fc26-x86_64_merged > # nsis-simple-service-plugin_4.1_create-rpms-fc24-x86_64_merged > # ovirt-engine-wildfly10_master_create-rpms-fc25-x86_64_created > # ovirt-engine-wildfly10_master_create-rpms-fc26-x86_64_created > # nsis-simple-service-plugin_4.1_create-rpms-fc24-x86_64_created > # tmp_ovirt-hosted-engine-ha_master_create-rpms-el7-x86_64_tagged > # nsis-simple-service-plugin_master_create-rpms-fc25-x86_64_merged > # ovirt-engine-wildfly-overlay10_4.1_create-rpms-el6-x86_64_merged > # ovirt-engine-wildfly-overlay10_4.1_create-rpms-el7-x86_64_merged > # nsis-simple-service-plugin_master_create-rpms-fc25-x86_64_created > # ovirt-engine-wildfly-overlay10_4.1_create-rpms-el6-x86_64_created > # ovirt-engine-wildfly-overlay10_4.1_create-rpms-el7-x86_64_created > # ovirt-engine-wildfly-overlay10_4.1_create-rpms-fc24-x86_64_merged > # ovirt-engine-wildfly-overlay10_4.1_create-rpms-fc24-x86_64_created > # ovirt-engine-wildfly-overlay10_master_create-rpms-el6-x86_64_merged > # ovirt-engine-wildfly-overlay10_master_create-rpms-el7-x86_64_merged > # ovirt-engine-wildfly-overlay10_master_create-rpms-el6-x86_64_created > # ovirt-engine-wildfly-overlay10_master_create-rpms-el7-x86_64_created > # ovirt-engine-wildfly-overlay10_master_create-rpms-fc25-x86_64_merged > # ovirt-engine-wildfly-overlay10_master_create-rpms-fc25-x86_64_created -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1626) Java Excpetion during CQ tester pipeline run
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1626?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1626: -------------------------------- Resolution: Cannot Reproduce Status: Done (was: To Do) Have`nt seen this happen again, closing with "cannot reproduce" > 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: Bug > 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 Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1626) Java Excpetion during CQ tester pipeline run
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1626?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1626: -------------------------------- Issue Type: Bug (was: New Feature) > 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: Bug > 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 Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1626) Java Excpetion during CQ tester pipeline run
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1626?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1626: -------------------------------- Epic Link: (was: 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 Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1626) Java Excpetion during CQ tester pipeline run
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1626?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1626: -------------------------------- Epic Link: (was: 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 Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1683) Add a type key to the list of available upstream sources
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1683?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1683: -------------------------------- Epic Link: (was: OVIRT-400) > Add a type key to the list of available upstream sources > -------------------------------------------------------- > > Key: OVIRT-1683 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1683 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: usrc.py > Reporter: Gil Shinar > Assignee: infra > > Currently, code supports the following upstream_sources.yaml file: > git: > - url: <git url> > commit: <git commit> > branch: <branch name> > and we need to support: > - type: git > url: <git url> > commit: <git commit> > branch: <branch name> > - type: svn > url: <svn url> > commit: <svn revision> > branch: <branch name> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1683) Add a type key to the list of available upstream sources
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1683?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1683: -------------------------------- Epic Link: (was: OVIRT-400) > Add a type key to the list of available upstream sources > -------------------------------------------------------- > > Key: OVIRT-1683 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1683 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: usrc.py > Reporter: Gil Shinar > Assignee: infra > > Currently, code supports the following upstream_sources.yaml file: > git: > - url: <git url> > commit: <git commit> > branch: <branch name> > and we need to support: > - type: git > url: <git url> > commit: <git commit> > branch: <branch name> > - type: svn > url: <svn url> > commit: <svn revision> > branch: <branch name> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1683) Add a type key to the list of available upstream sources
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1683?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1683: -------------------------------- Issue Type: New Feature (was: Task) > Add a type key to the list of available upstream sources > -------------------------------------------------------- > > Key: OVIRT-1683 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1683 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: usrc.py > Reporter: Gil Shinar > Assignee: infra > > Currently, code supports the following upstream_sources.yaml file: > git: > - url: <git url> > commit: <git commit> > branch: <branch name> > and we need to support: > - type: git > url: <git url> > commit: <git commit> > branch: <branch name> > - type: svn > url: <svn url> > commit: <svn revision> > branch: <branch name> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1683) Add a type key to the list of available upstream sources
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1683?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1683: -------------------------------- Component/s: usrc.py > Add a type key to the list of available upstream sources > -------------------------------------------------------- > > Key: OVIRT-1683 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1683 > Project: oVirt - virtualization made easy > Issue Type: Task > Components: usrc.py > Reporter: Gil Shinar > Assignee: infra > > Currently, code supports the following upstream_sources.yaml file: > git: > - url: <git url> > commit: <git commit> > branch: <branch name> > and we need to support: > - type: git > url: <git url> > commit: <git commit> > branch: <branch name> > - type: svn > url: <svn url> > commit: <svn revision> > branch: <branch name> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1689) Improve error messages in STDCI environment variable handling
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1689?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1689: -------------------------------- Epic Link: (was: OVIRT-400) > Improve error messages in STDCI environment variable handling > ------------------------------------------------------------- > > Key: OVIRT-1689 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1689 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: mock_runner > Reporter: Daniel Belenky > Assignee: infra > > * All references to things like 'xdg-home' need to be replaced with specifications of actual paths, as users are not expected to know what XDG is. > * Accurate indication of what is missing from which file and what can be done to fix it need to be given in all error messages. > * When variable/key names are given in error messages, they need to be quoted for clarity. > * Edge cases like for example an existing but empty secrets file and a missing 'secrets_data' key need to be handled better, with clear error messages > * Error message when a requested env var is missing needs to be improved to tell the user what to do. Current message can be very confusing when trying to use 'mock_runner.sh' for the 'jenkins' repo for example. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1689) Improve error messages in STDCI environment variable handling
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1689?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1689: -------------------------------- Epic Link: (was: OVIRT-400) > Improve error messages in STDCI environment variable handling > ------------------------------------------------------------- > > Key: OVIRT-1689 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1689 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: mock_runner > Reporter: Daniel Belenky > Assignee: infra > > * All references to things like 'xdg-home' need to be replaced with specifications of actual paths, as users are not expected to know what XDG is. > * Accurate indication of what is missing from which file and what can be done to fix it need to be given in all error messages. > * When variable/key names are given in error messages, they need to be quoted for clarity. > * Edge cases like for example an existing but empty secrets file and a missing 'secrets_data' key need to be handled better, with clear error messages > * Error message when a requested env var is missing needs to be improved to tell the user what to do. Current message can be very confusing when trying to use 'mock_runner.sh' for the 'jenkins' repo for example. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1690) Add CI for groovy/pipeline code in 'jenkins' repo
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1690?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1690: -------------------------------- Epic Link: (was: OVIRT-400) > Add CI for groovy/pipeline code in 'jenkins' repo > ------------------------------------------------- > > Key: OVIRT-1690 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1690 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: CI client projects > Reporter: Barak Korren > Assignee: infra > Labels: first_time_task, groovy, jenkins > > We don't have any CI for Groovy code currently. > At the very least we need to check that the code compiles, this is a bit harder then it sounds because in order to test compilation for piepline code we need to mock out things like the '{{NonCPS}}' decorator which is not supported by the standard Groovy compiler. > Ideally we can also ass support for a full test suit. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1690) Add CI for groovy/pipeline code in 'jenkins' repo
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1690?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1690: -------------------------------- Epic Link: (was: OVIRT-400) > Add CI for groovy/pipeline code in 'jenkins' repo > ------------------------------------------------- > > Key: OVIRT-1690 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1690 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: CI client projects > Reporter: Barak Korren > Assignee: infra > Labels: first_time_task, groovy, jenkins > > We don't have any CI for Groovy code currently. > At the very least we need to check that the code compiles, this is a bit harder then it sounds because in order to test compilation for piepline code we need to mock out things like the '{{NonCPS}}' decorator which is not supported by the standard Groovy compiler. > Ideally we can also ass support for a full test suit. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1704) Add a job to update/modify secrets file
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1704?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1704: -------------------------------- Epic Link: (was: OVIRT-400) > Add a job to update/modify secrets file > --------------------------------------- > > Key: OVIRT-1704 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1704 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Reporter: Daniel Belenky > Assignee: infra > Labels: first_time_task > > We need to have a proper way to update/modify the secrets file which is stored in our Jenkins server. > The alternative is having to add a way to download then update locally and upload again. > If we choose to allow downloading the file, we need to make it convenient and safe so that users which are unauthorized won't be able to download it. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1704) Add a job to update/modify secrets file
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1704?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1704: -------------------------------- Epic Link: (was: OVIRT-400) > Add a job to update/modify secrets file > --------------------------------------- > > Key: OVIRT-1704 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1704 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Reporter: Daniel Belenky > Assignee: infra > Labels: first_time_task > > We need to have a proper way to update/modify the secrets file which is stored in our Jenkins server. > The alternative is having to add a way to download then update locally and upload again. > If we choose to allow downloading the file, we need to make it convenient and safe so that users which are unauthorized won't be able to download it. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1732) Make 'poll-upstream-chages' job abandon old changes it made
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1732?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1732: -------------------------------- Epic Link: (was: OVIRT-400) > Make 'poll-upstream-chages' job abandon old changes it made > ----------------------------------------------------------- > > Key: OVIRT-1732 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1732 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: pusher.py > Reporter: Barak Korren > Assignee: infra > Labels: poll-upstream-sources, standard-ci > > The poll-upstream-changes job creates patches when it runs. Not all these patches need or should be merged. When maintainers get around to looking at them, they typically can just merge the latest patch and throw away the rest. > The issue is that over time, the patches created by the job can accumulate, and it can be cumbersome for maintainers to remove un-needed ones manually. > We should make the poll job remove un-needed patches it made. It needs to look at the last SHA in the upstream-sources.yaml file, and remove all that patches that include an older SHA automatically. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1732) Make 'poll-upstream-chages' job abandon old changes it made
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1732?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1732: -------------------------------- Epic Link: (was: OVIRT-400) > Make 'poll-upstream-chages' job abandon old changes it made > ----------------------------------------------------------- > > Key: OVIRT-1732 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1732 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: pusher.py > Reporter: Barak Korren > Assignee: infra > Labels: poll-upstream-sources, standard-ci > > The poll-upstream-changes job creates patches when it runs. Not all these patches need or should be merged. When maintainers get around to looking at them, they typically can just merge the latest patch and throw away the rest. > The issue is that over time, the patches created by the job can accumulate, and it can be cumbersome for maintainers to remove un-needed ones manually. > We should make the poll job remove un-needed patches it made. It needs to look at the last SHA in the upstream-sources.yaml file, and remove all that patches that include an older SHA automatically. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1734) Add CI jobs to test slaves on staging engine
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1734?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1734: -------------------------------- Resolution: Fixed Status: Done (was: To Do) We already have multiple test jobs and projects on the staging system > Add CI jobs to test slaves on staging engine > -------------------------------------------- > > Key: OVIRT-1734 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1734 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: CI client projects, Jenkins Slaves, Staging infra, Standard CI (Freestyle) > Reporter: Barak Korren > Assignee: infra > Labels: staging > > After the staging engine was installed, several VMs were created on it and added as slaves to the staging Jenkins. > We need to add some jobs that will take advantage on those slaves so we can tell if they are working properly. > The should probably just add CI jobs for the 'jenkins' repo. That repo is already configured to run some jobs on the staging Jenkins and is mostly maintained by our team, so and issues there will be visible to us. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1734) Add CI jobs to test slaves on staging engine
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1734?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1734: -------------------------------- Epic Link: (was: OVIRT-400) > Add CI jobs to test slaves on staging engine > -------------------------------------------- > > Key: OVIRT-1734 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1734 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: CI client projects, Jenkins Slaves, Staging infra, Standard CI (Freestyle) > Reporter: Barak Korren > Assignee: infra > Labels: staging > > After the staging engine was installed, several VMs were created on it and added as slaves to the staging Jenkins. > We need to add some jobs that will take advantage on those slaves so we can tell if they are working properly. > The should probably just add CI jobs for the 'jenkins' repo. That repo is already configured to run some jobs on the staging Jenkins and is mostly maintained by our team, so and issues there will be visible to us. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1734) Add CI jobs to test slaves on staging engine
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1734?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1734: -------------------------------- Epic Link: (was: OVIRT-400) > Add CI jobs to test slaves on staging engine > -------------------------------------------- > > Key: OVIRT-1734 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1734 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: CI client projects, Jenkins Slaves, Staging infra, Standard CI (Freestyle) > Reporter: Barak Korren > Assignee: infra > Labels: staging > > After the staging engine was installed, several VMs were created on it and added as slaves to the staging Jenkins. > We need to add some jobs that will take advantage on those slaves so we can tell if they are working properly. > The should probably just add CI jobs for the 'jenkins' repo. That repo is already configured to run some jobs on the staging Jenkins and is mostly maintained by our team, so and issues there will be visible to us. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1737) cleanup_lago method in cleanup_slave.sh should have a return status
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1737?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1737: -------------------------------- Epic Link: (was: OVIRT-400) > cleanup_lago method in cleanup_slave.sh should have a return status > ------------------------------------------------------------------- > > Key: OVIRT-1737 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1737 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Jenkins Slaves > Reporter: Daniel Belenky > Assignee: infra > Priority: Low > > Currently, the method doesn't return the return code from it's submethods to 'main'. This needs to be fixed. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1737) cleanup_lago method in cleanup_slave.sh should have a return status
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1737?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1737: -------------------------------- Epic Link: (was: OVIRT-400) > cleanup_lago method in cleanup_slave.sh should have a return status > ------------------------------------------------------------------- > > Key: OVIRT-1737 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1737 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Jenkins Slaves > Reporter: Daniel Belenky > Assignee: infra > Priority: Low > > Currently, the method doesn't return the return code from it's submethods to 'main'. This needs to be fixed. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1737) cleanup_lago method in cleanup_slave.sh should have a return status
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1737?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1737: -------------------------------- Component/s: Jenkins Slaves > cleanup_lago method in cleanup_slave.sh should have a return status > ------------------------------------------------------------------- > > Key: OVIRT-1737 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1737 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Jenkins Slaves > Reporter: Daniel Belenky > Assignee: infra > Priority: Low > > Currently, the method doesn't return the return code from it's submethods to 'main'. This needs to be fixed. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1739) Unified code owners mechanism between Gerrit and GitHub
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1739?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1739: -------------------------------- Epic Link: (was: OVIRT-400) > Unified code owners mechanism between Gerrit and GitHub > ------------------------------------------------------- > > Key: OVIRT-1739 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1739 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Gerrit/git, GitHub, Standard CI (Freestyle), Standard CI (Pipelines), STDCI DSL > Reporter: Barak Korren > Assignee: infra > Labels: gerrit, github, reviewers, standard-ci > > "Code owners" is the mechanism that automatically assigns reviewers to new code patches. > In Gerrit we use the "reviewers" plugin to automatically set reviewers (See OVIRT-1165). > GitHub has its own mechanism: https://github.com/blog/2392-introducing-code-owners > We would like to have a unified way for oVirt devs to do this regardless of the code hosting platform. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1739) Unified code owners mechanism between Gerrit and GitHub
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1739?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1739: -------------------------------- Epic Link: (was: OVIRT-400) > Unified code owners mechanism between Gerrit and GitHub > ------------------------------------------------------- > > Key: OVIRT-1739 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1739 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Gerrit/git, GitHub, Standard CI (Freestyle), Standard CI (Pipelines), STDCI DSL > Reporter: Barak Korren > Assignee: infra > Labels: gerrit, github, reviewers, standard-ci > > "Code owners" is the mechanism that automatically assigns reviewers to new code patches. > In Gerrit we use the "reviewers" plugin to automatically set reviewers (See OVIRT-1165). > GitHub has its own mechanism: https://github.com/blog/2392-introducing-code-owners > We would like to have a unified way for oVirt devs to do this regardless of the code hosting platform. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1743) ci please build and send to OST
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1743?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1743: -------------------------------- Epic Link: (was: OVIRT-400) > ci please build and send to OST > ------------------------------- > > Key: OVIRT-1743 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1743 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: OST Manual job, Standard CI (Freestyle) > Reporter: danken > Assignee: infra > Labels: change-queue > > Can you please automate the frequent process, which is slow and error prone? > I am writing a patch, and would like to test it in ost. now I need to > * "ci please build" > * copy el7 url > * wait for el7 build to finish > * copy artifacts url to ovirt--system-test-manual, start it > * copy the ost run URL to the gerrit patch, so I have it for reference of failure/success. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1743) ci please build and send to OST
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1743?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1743: -------------------------------- Epic Link: (was: OVIRT-400) > ci please build and send to OST > ------------------------------- > > Key: OVIRT-1743 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1743 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: OST Manual job, Standard CI (Freestyle) > Reporter: danken > Assignee: infra > Labels: change-queue > > Can you please automate the frequent process, which is slow and error prone? > I am writing a patch, and would like to test it in ost. now I need to > * "ci please build" > * copy el7 url > * wait for el7 build to finish > * copy artifacts url to ovirt--system-test-manual, start it > * copy the ost run URL to the gerrit patch, so I have it for reference of failure/success. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1759) Gerrit patches can reach CQ out-of-order
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1759?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1759: -------------------------------- Epic Link: (was: OVIRT-400) > Gerrit patches can reach CQ out-of-order > ---------------------------------------- > > Key: OVIRT-1759 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1759 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Change Queue, Gerrit/git > Reporter: Barak Korren > Assignee: infra > Priority: High > Labels: change-queue, gerrit > > Is seems that despite the fact that all the jobs involved were designed to preserve proper patch ordering, there can be cases where patches trigger Jenkins jobs in the wrong order, which in turn end up putting the patches in the wrong order into the CQ. This in turn, causes the CQ to fail accurately detecting the patches that cause issues. > Here is en example of such an occurance. The following patches were merged in the order specified below: > # https://gerrit.ovirt.org/c/83917 > # https://gerrit.ovirt.org/c/83918 > # https://gerrit.ovirt.org/c/83919 > # https://gerrit.ovirt.org/c/83920 > The standard-enqueue runs putting them in the CQ however, seem to have run in a different order: > # http://jenkins.ovirt.org/job/standard-enqueue/6712/ (83917) > # http://jenkins.ovirt.org/job/standard-enqueue/6713/ (83919) > # http://jenkins.ovirt.org/job/standard-enqueue/6714/ (83920) > # http://jenkins.ovirt.org/job/standard-enqueue/6715/ (83918) > This resulted in CQ 'add' command running in the wrong order: > # http://jenkins.ovirt.org/job/ovirt-master_change-queue/12200/ (add 83917) > # http://jenkins.ovirt.org/job/ovirt-master_change-queue/12201/ (add 83919) > # http://jenkins.ovirt.org/job/ovirt-master_change-queue/12202/ (add 83920) > # http://jenkins.ovirt.org/job/ovirt-master_change-queue/12203/ (add 83918) > We need to come up with a way to make the system properly preserver order. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1759) Gerrit patches can reach CQ out-of-order
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1759?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1759: -------------------------------- Epic Link: (was: OVIRT-400) > Gerrit patches can reach CQ out-of-order > ---------------------------------------- > > Key: OVIRT-1759 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1759 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Change Queue, Gerrit/git > Reporter: Barak Korren > Assignee: infra > Priority: High > Labels: change-queue, gerrit > > Is seems that despite the fact that all the jobs involved were designed to preserve proper patch ordering, there can be cases where patches trigger Jenkins jobs in the wrong order, which in turn end up putting the patches in the wrong order into the CQ. This in turn, causes the CQ to fail accurately detecting the patches that cause issues. > Here is en example of such an occurance. The following patches were merged in the order specified below: > # https://gerrit.ovirt.org/c/83917 > # https://gerrit.ovirt.org/c/83918 > # https://gerrit.ovirt.org/c/83919 > # https://gerrit.ovirt.org/c/83920 > The standard-enqueue runs putting them in the CQ however, seem to have run in a different order: > # http://jenkins.ovirt.org/job/standard-enqueue/6712/ (83917) > # http://jenkins.ovirt.org/job/standard-enqueue/6713/ (83919) > # http://jenkins.ovirt.org/job/standard-enqueue/6714/ (83920) > # http://jenkins.ovirt.org/job/standard-enqueue/6715/ (83918) > This resulted in CQ 'add' command running in the wrong order: > # http://jenkins.ovirt.org/job/ovirt-master_change-queue/12200/ (add 83917) > # http://jenkins.ovirt.org/job/ovirt-master_change-queue/12201/ (add 83919) > # http://jenkins.ovirt.org/job/ovirt-master_change-queue/12202/ (add 83920) > # http://jenkins.ovirt.org/job/ovirt-master_change-queue/12203/ (add 83918) > We need to come up with a way to make the system properly preserver order. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1774) Upstream source collector can fail to push on multi-branch projects
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1774?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1774: -------------------------------- Epic Link: (was: OVIRT-400) > Upstream source collector can fail to push on multi-branch projects > ------------------------------------------------------------------- > > Key: OVIRT-1774 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1774 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: pusher.py > Reporter: Barak Korren > Assignee: infra > Labels: poll-upstream-sources, upstream-source-collector > > When the upstream source collection code looks for similar patches in order to avoid pushing a new patch, it lookes for patches that contain the same change to the '{{upstream-sources.yaml}}' file, regardless of the branch they may belong to. > The code currently ignores the possibility that similar changes might be required for different branches, in which case different patches may need to be pushed. > The way of detecting similar patches should be changed so that either the branch name is included in the checksum that are used to identify a patch, or the query is limited to patches of the branch being handled. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1774) Upstream source collector can fail to push on multi-branch projects
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1774?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1774: -------------------------------- Epic Link: (was: OVIRT-400) > Upstream source collector can fail to push on multi-branch projects > ------------------------------------------------------------------- > > Key: OVIRT-1774 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1774 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: pusher.py > Reporter: Barak Korren > Assignee: infra > Labels: poll-upstream-sources, upstream-source-collector > > When the upstream source collection code looks for similar patches in order to avoid pushing a new patch, it lookes for patches that contain the same change to the '{{upstream-sources.yaml}}' file, regardless of the branch they may belong to. > The code currently ignores the possibility that similar changes might be required for different branches, in which case different patches may need to be pushed. > The way of detecting similar patches should be changed so that either the branch name is included in the checksum that are used to identify a patch, or the query is limited to patches of the branch being handled. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1782) Make sure all VDSM build dependencies for FC27 are met.
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1782?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1782: -------------------------------- Resolution: Won't Fix Status: Done (was: To Do) VDSM development had already moved on to FC28 > Make sure all VDSM build dependencies for FC27 are met. > ------------------------------------------------------- > > Key: OVIRT-1782 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1782 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: CI client projects > Reporter: Barak Korren > Assignee: infra > Labels: vdsm > > There had been attempts recently to make VDSM build on FC27. > Those attempts were met with mixed success as issues kept surfacing. > Fro now all the FC27 jobs for VDSM had been disabled. > This ticket is for racking work of debugging issues to re-enable the jobs -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1831) Make `global-setup.sh` check if packages are installed before trying to install them
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1831?page=com.atlassian.jira.… ] Barak Korren reassigned OVIRT-1831: ----------------------------------- Assignee: (was: infra) > Make `global-setup.sh` check if packages are installed before trying to install them > ------------------------------------------------------------------------------------ > > Key: OVIRT-1831 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1831 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins Slaves > Reporter: Barak Korren > > The way '{{global-setup.sh}}' works currently is that it tries to install all the packages it needs in a single yum command and then runs in a loop and checks if the packages were installed properly. > If the packages are already installed this takes a negligible amount of time on CentOS slaves, but on Fedora it seems to take much longer and as much as 2 minutes. > We should try to make '{{global-setup.sh}}' faster by making it not try to install packages before checking if they are there, but instead check first and only try to install the missing ones. > Note that if we'll install multiple packages in a single command, we'll still need to verify they were properly installed after the yum/dnf command finishes. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1836) Optimize options normalization methods in stdci_dsl
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1836?page=com.atlassian.jira.… ] Barak Korren reassigned OVIRT-1836: ----------------------------------- Assignee: (was: infra) > Optimize options normalization methods in stdci_dsl > --------------------------------------------------- > > Key: OVIRT-1836 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1836 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: STDCI DSL > Reporter: Daniel Belenky > > Generally, we have 4 kinds of options: script, globals, options that affect host selection and options to configure the runner. > We need to take care of global options first since they affect everything, then take care of script because it tells which vectors to throw away. > Since runners and pipelines care about different sets of options, we need to split the options handling functions. > This will enable us to compose much more efficient pipelines in the API. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1864) investigate why vdsm check-merged job fails on non el7 hosts
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1864?page=com.atlassian.jira.… ] Barak Korren reassigned OVIRT-1864: ----------------------------------- Assignee: (was: infra) > investigate why vdsm check-merged job fails on non el7 hosts > ------------------------------------------------------------ > > Key: OVIRT-1864 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1864 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: CI client projects > Reporter: Daniel Belenky > > It seems that vdsm check-merged job fails on non el7 hosts. It just times out. > Maybe el7 hosts are faster(?) > For now, [https://gerrit.ovirt.org/#/c/86780/|https://gerrit.ovirt.org/#/c/86780/] bounds vdsm check-merged to run on el7 hosts only. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1831) Make `global-setup.sh` check if packages are installed before trying to install them
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1831?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1831: -------------------------------- Epic Link: (was: OVIRT-400) > Make `global-setup.sh` check if packages are installed before trying to install them > ------------------------------------------------------------------------------------ > > Key: OVIRT-1831 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1831 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins Slaves > Reporter: Barak Korren > Assignee: infra > > The way '{{global-setup.sh}}' works currently is that it tries to install all the packages it needs in a single yum command and then runs in a loop and checks if the packages were installed properly. > If the packages are already installed this takes a negligible amount of time on CentOS slaves, but on Fedora it seems to take much longer and as much as 2 minutes. > We should try to make '{{global-setup.sh}}' faster by making it not try to install packages before checking if they are there, but instead check first and only try to install the missing ones. > Note that if we'll install multiple packages in a single command, we'll still need to verify they were properly installed after the yum/dnf command finishes. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1831) Make `global-setup.sh` check if packages are installed before trying to install them
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1831?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1831: -------------------------------- Epic Link: (was: OVIRT-400) > Make `global-setup.sh` check if packages are installed before trying to install them > ------------------------------------------------------------------------------------ > > Key: OVIRT-1831 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1831 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins Slaves > Reporter: Barak Korren > Assignee: infra > > The way '{{global-setup.sh}}' works currently is that it tries to install all the packages it needs in a single yum command and then runs in a loop and checks if the packages were installed properly. > If the packages are already installed this takes a negligible amount of time on CentOS slaves, but on Fedora it seems to take much longer and as much as 2 minutes. > We should try to make '{{global-setup.sh}}' faster by making it not try to install packages before checking if they are there, but instead check first and only try to install the missing ones. > Note that if we'll install multiple packages in a single command, we'll still need to verify they were properly installed after the yum/dnf command finishes. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1836) Optimize options normalization methods in stdci_dsl
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1836?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1836: -------------------------------- Epic Link: (was: OVIRT-400) > Optimize options normalization methods in stdci_dsl > --------------------------------------------------- > > Key: OVIRT-1836 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1836 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: STDCI DSL > Reporter: Daniel Belenky > Assignee: infra > > Generally, we have 4 kinds of options: script, globals, options that affect host selection and options to configure the runner. > We need to take care of global options first since they affect everything, then take care of script because it tells which vectors to throw away. > Since runners and pipelines care about different sets of options, we need to split the options handling functions. > This will enable us to compose much more efficient pipelines in the API. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1836) Optimize options normalization methods in stdci_dsl
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1836?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1836: -------------------------------- Epic Link: (was: OVIRT-400) > Optimize options normalization methods in stdci_dsl > --------------------------------------------------- > > Key: OVIRT-1836 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1836 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: STDCI DSL > Reporter: Daniel Belenky > Assignee: infra > > Generally, we have 4 kinds of options: script, globals, options that affect host selection and options to configure the runner. > We need to take care of global options first since they affect everything, then take care of script because it tells which vectors to throw away. > Since runners and pipelines care about different sets of options, we need to split the options handling functions. > This will enable us to compose much more efficient pipelines in the API. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1864) investigate why vdsm check-merged job fails on non el7 hosts
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1864?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1864: -------------------------------- Component/s: CI client projects > investigate why vdsm check-merged job fails on non el7 hosts > ------------------------------------------------------------ > > Key: OVIRT-1864 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1864 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: CI client projects > Reporter: Daniel Belenky > Assignee: infra > > It seems that vdsm check-merged job fails on non el7 hosts. It just times out. > Maybe el7 hosts are faster(?) > For now, [https://gerrit.ovirt.org/#/c/86780/|https://gerrit.ovirt.org/#/c/86780/] bounds vdsm check-merged to run on el7 hosts only. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1864) investigate why vdsm check-merged job fails on non el7 hosts
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1864?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1864: -------------------------------- Epic Link: (was: OVIRT-400) > investigate why vdsm check-merged job fails on non el7 hosts > ------------------------------------------------------------ > > Key: OVIRT-1864 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1864 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Daniel Belenky > Assignee: infra > > It seems that vdsm check-merged job fails on non el7 hosts. It just times out. > Maybe el7 hosts are faster(?) > For now, [https://gerrit.ovirt.org/#/c/86780/|https://gerrit.ovirt.org/#/c/86780/] bounds vdsm check-merged to run on el7 hosts only. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1864) investigate why vdsm check-merged job fails on non el7 hosts
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1864?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1864: -------------------------------- Epic Link: (was: OVIRT-400) > investigate why vdsm check-merged job fails on non el7 hosts > ------------------------------------------------------------ > > Key: OVIRT-1864 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1864 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Daniel Belenky > Assignee: infra > > It seems that vdsm check-merged job fails on non el7 hosts. It just times out. > Maybe el7 hosts are faster(?) > For now, [https://gerrit.ovirt.org/#/c/86780/|https://gerrit.ovirt.org/#/c/86780/] bounds vdsm check-merged to run on el7 hosts only. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2178) "Borrow" slaves from CentOS CI
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2178?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-2178: ------------------------------------- The command line tool for using Duffy is [cico|http://python-cicoclient.readthedocs.io/en/latest/cli_usage.html] > "Borrow" slaves from CentOS CI > ------------------------------ > > Key: OVIRT-2178 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2178 > Project: oVirt - virtualization made easy > Issue Type: Epic > Reporter: Barak Korren > Assignee: infra > > [CentOS CI|https://wiki.centos.org/QaWiki/CI] is a generic shared platform for building CI service for Open Source projects. > Amount other things, CentOS CI makes physical and virtual hosts available for running CI processes via the [Duffy|http://wiki.centos.org/QaWiki/CI/Duffy] system. > We should make oVirt CI able to consume resources from CentOs CI to augment and someday replace the hardware resources available to oVirt CI. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2230) Checkout using prow as a GitHub triggering mechanism
by Barak Korren (oVirt JIRA) 24 Jun '18

24 Jun '18

Barak Korren created OVIRT-2230: ----------------------------------- Summary: Checkout using prow as a GitHub triggering mechanism Key: OVIRT-2230 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2230 Project: oVirt - virtualization made easy Issue Type: New Feature Components: Jenkins Master Reporter: Barak Korren Assignee: infra [Prow|https://github.com/kubernetes/test-infra/tree/master/prow] is the service that Kubernetes are using to trigger their CI on GitHub events. We should inspect it and see if it would be useful for us to adopt it. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[oVirt Jenkins] ovirt-system-tests_he-basic-iscsi-suite-master - Build # 271 - Failure!
by jenkins＠jenkins.phx.ovirt.org 24 Jun '18

24 Jun '18

Project: http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-iscsi-suite-master/ Build: http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-iscsi-suite-master… Build Number: 271 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #271 [Sandro Bonazzola] yum-repos: master: adjusted for new packages ----------------- Failed Tests: ----------------- All tests passed

1 1

[oVirt Jenkins] ovirt-system-tests_he-basic-iscsi-suite-4.2 - Build # 60 - Failure!
by jenkins＠jenkins.phx.ovirt.org 23 Jun '18

23 Jun '18

Project: http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-iscsi-suite-4.2/ Build: http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-iscsi-suite-4.2/60/ Build Number: 60 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #60 [Sandro Bonazzola] yum-repos: master: adjusted for new packages ----------------- Failed Tests: ----------------- All tests passed

1 2