- Infra - oVirt List Archives

[JIRA] (OVIRT-1043) Make build_artifacts create yum metadata if RMS were created
by Barak Korren (oVirt JIRA) 17 Jan '17

17 Jan '17

Barak Korren created OVIRT-1043: ----------------------------------- Summary: Make build_artifacts create yum metadata if RMS were created Key: OVIRT-1043 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1043 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Jenkins Reporter: Barak Korren Assignee: infra Priority: High HAving each build_artifacts run generate its own little repo has various use cases. One of the main ones as to allow syncing artifacts with 'reposync' into transactional mirrors (OVIRT-1041) -- This message was sent by Atlassian JIRA (v1000.695.1#100025)

1 0

[JIRA] (OVIRT-1043) Make build_artifacts create yum metadata if RMS were created
by Barak Korren (oVirt JIRA) 17 Jan '17

17 Jan '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1043?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1043: -------------------------------- Epic Link: OVIRT-400 > Make build_artifacts create yum metadata if RMS were created > ------------------------------------------------------------ > > Key: OVIRT-1043 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1043 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > Priority: High > Labels: standard-ci > > HAving each build_artifacts run generate its own little repo has various use cases. One of the main ones as to allow syncing artifacts with 'reposync' into transactional mirrors (OVIRT-1041) -- This message was sent by Atlassian JIRA (v1000.695.1#100025)

1 0

[JIRA] (OVIRT-1040) ovirt-engine_4.1_check-patch-fc25-x86_64 build has failed
by Evgheni Dereveanchin (oVirt JIRA) 17 Jan '17

17 Jan '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1040?page=com.atlassian.jira.… ] Evgheni Dereveanchin commented on OVIRT-1040: --------------------------------------------- [~eedri] there's a java null pointer exception in the log. Why do you think it's related to the host? We're running in mock anyways so host binaries shouldn't be used, right? > ovirt-engine_4.1_check-patch-fc25-x86_64 build has failed > --------------------------------------------------------- > > Key: OVIRT-1040 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1040 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Yevgeny Zaspitsky > Assignee: infra > > The $subject job [1] has failed upon a reason that doesn't seems to be > related to the patch it checks. > From the check_patch.sh.log: > [INFO] --- exec-maven-plugin:1.4.0:java (generate-enums-jaxb) @ > restapi-definition --- > SLF4J: Class path contains multiple SLF4J bindings. > SLF4J: Found binding in > [jar:file:/root/.m2/repository/org/slf4j/slf4j-log4j12/1.7.7/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: Found binding in > [jar:file:/root/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar!/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. > SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory] > [WARNING] > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:293) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at com.google.common.collect.AbstractMapBasedMultimap.wrapList(AbstractMapBasedMultimap.java:332) > at com.google.common.collect.AbstractMapBasedMultimap.wrapCollection(AbstractMapBasedMultimap.java:324) > at com.google.common.collect.AbstractMapBasedMultimap.get(AbstractMapBasedMultimap.java:308) > at com.google.common.collect.AbstractListMultimap.get(AbstractListMultimap.java:66) > at com.google.common.collect.ArrayListMultimap.get(ArrayListMultimap.java:66) > at org.jboss.weld.annotated.enhanced.jlr.EnhancedAnnotatedTypeImpl.getDeclaredEnhancedFields(EnhancedAnnotatedTypeImpl.java:427) > at org.jboss.weld.injection.InjectionPointFactory.getFieldInjectionPoints(InjectionPointFactory.java:210) > at org.jboss.weld.injection.producer.DefaultInjector.<init>(DefaultInjector.java:56) > at org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:58) > at org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49) > at org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:63) > at org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:47) > at org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:128) > at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87) > at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:100) > at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:80) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:261) > at org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:228) > at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78) > at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > ... 1 more > [WARNING] thread Thread[weld-worker-1,5,weld-workers] was interrupted > but is still alive after waiting at least 15000msecs > [WARNING] thread Thread[weld-worker-1,5,weld-workers] will linger > despite being asked to die via interruption > [WARNING] thread Thread[weld-worker-2,5,weld-workers] will linger > despite being asked to die via interruption > [WARNING] NOTE: 2 thread(s) did not finish despite being asked to via > interruption. This is not a problem with exec:java, it is a problem > with the running code. Although not serious, it should be remedied. > [WARNING] Couldn't destroy threadgroup > org.codehaus.mojo.exec.ExecJavaMojo$IsolatedThreadGroup[name=org.ovirt.api.metamodel.tool.Main,maxpri=10] > java.lang.IllegalThreadStateException > at java.lang.ThreadGroup.destroy(ThreadGroup.java:778) > at java.lang.ThreadGroup.destroy(ThreadGroup.java:795) > at org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:328) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) > at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > [1] - > http://jenkins.ovirt.org/job/ovirt-engine_4.1_check-patch-fc25-x86_64/281/ -- This message was sent by Atlassian JIRA (v1000.695.1#100025)

1 0

[JIRA] (OVIRT-1041) Base experimantal flow on transactional repos
by Barak Korren (oVirt JIRA) 17 Jan '17

17 Jan '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1041?page=com.atlassian.jira.… ] Barak Korren reassigned OVIRT-1041: ----------------------------------- Assignee: Barak Korren (was: infra) > Base experimantal flow on transactional repos > --------------------------------------------- > > Key: OVIRT-1041 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1041 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Repositories Mgmt > Reporter: Barak Korren > Assignee: Barak Korren > Priority: High > > We recently seen various issues with the way the experimental repos are managed: > * The latest.tested repos is close to unusable because it changes very rapidly and does not keep history around > * Its impossible to have more then one experimental flow running in parallel because there can be only one latest.under_test repo > * We've seem various race conditions happening with the experimental repos because they are manipulated both by the 'deploy-to-experimental' jobs and by the 'test-repo' jobs. > * The experimental repo is manipulated by various secret and undocumented scripts in resources.ovirt.org. This makes things hard to debug. > * It is close to impossible to reproduce experimental runs because the exact repo used for those runs acn get destroyed as soon as the run is done > We've recently created the technology to maintain transactional mirrors (see OVIRT-575). It is desirable to use the same technique for managing the experimental repos. > Here is a breakdown of the steps to accomplish this task: > # The mirrors management script needs YUM repos to sync from. We can actually make each build_artifacts jobs generate its own mini repo by running 'createrepo' in 'exported-artifacts'. > # We need to make the 'deploy-to-experimental' job run the mirror management script to sync built artifacts into the relevant repo and create a snapshot. > # Once we have the above, we can treat the experimental repo just like any other repo in the OST reposync file. The same work that will be done to inject mirrors into the experimental flow can also inject the experimental repo snapshots. > # If we still want the experimental 'latest.tested' to be published on resources.ovirt.org, we can just 'reposync' it from the mirrors server once the OST run is successful. That published repo can include package and metadata history is it can be used by external consumers even if it changes frequently. -- This message was sent by Atlassian JIRA (v1000.695.1#100025)

1 0

[JIRA] (OVIRT-1042) Make OST experimental flow use mirrors
by Barak Korren (oVirt JIRA) 17 Jan '17

17 Jan '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1042?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1042: -------------------------------- Epic Link: OVIRT-400 > Make OST experimental flow use mirrors > -------------------------------------- > > Key: OVIRT-1042 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1042 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Repositories Mgmt > Reporter: Barak Korren > Assignee: infra > Priority: High > Labels: system-tests > > Right now the mirrors had be integrated only into mock-runner.sh. We need to have OST use the mirrors too. -- This message was sent by Atlassian JIRA (v1000.695.1#100025)

1 0

[JIRA] (OVIRT-1042) Make OST experimental flow use mirrors
by Barak Korren (oVirt JIRA) 17 Jan '17

17 Jan '17

Barak Korren created OVIRT-1042: ----------------------------------- Summary: Make OST experimental flow use mirrors Key: OVIRT-1042 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1042 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Repositories Mgmt Reporter: Barak Korren Assignee: infra Priority: High Right now the mirrors had be integrated only into mock-runner.sh. We need to have OST use the mirrors too. -- This message was sent by Atlassian JIRA (v1000.695.1#100025)

1 0

[JIRA] (OVIRT-1041) Base experimantal flow on transactional repos
by Barak Korren (oVirt JIRA) 17 Jan '17

17 Jan '17

Barak Korren created OVIRT-1041: ----------------------------------- Summary: Base experimantal flow on transactional repos Key: OVIRT-1041 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1041 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Repositories Mgmt Reporter: Barak Korren Assignee: infra Priority: High We recently seen various issues with the way the experimental repos are managed: * The latest.tested repos is close to unusable because it changes very rapidly and does not keep history around * Its impossible to have more then one experimental flow running in parallel because there can be only one latest.under_test repo * We've seem various race conditions happening with the experimental repos because they are manipulated both by the 'deploy-to-experimental' jobs and by the 'test-repo' jobs. * The experimental repo is manipulated by various secret and undocumented scripts in resources.ovirt.org. This makes things hard to debug. * It is close to impossible to reproduce experimental runs because the exact repo used for those runs acn get destroyed as soon as the run is done We've recently created the technology to maintain transactional mirrors (see OVIRT-575). It is desirable to use the same technique for managing the experimental repos. Here is a breakdown of the steps to accomplish this task: # The mirrors management script needs YUM repos to sync from. We can actually make each build_artifacts jobs generate its own mini repo by running 'createrepo' in 'exported-artifacts'. # We need to make the 'deploy-to-experimental' job run the mirror management script to sync built artifacts into the relevant repo and create a snapshot. # Once we have the above, we can treat the experimental repo just like any other repo in the OST reposync file. The same work that will be done to inject mirrors into the experimental flow can also inject the experimental repo snapshots. # If we still want the experimental 'latest.tested' to be published on resources.ovirt.org, we can just 'reposync' it from the mirrors server once the OST run is successful. That published repo can include package and metadata history is it can be used by external consumers even if it changes frequently. -- This message was sent by Atlassian JIRA (v1000.695.1#100025)

1 0

[JIRA] (OVIRT-1041) Base experimantal flow on transactional repos
by Barak Korren (oVirt JIRA) 17 Jan '17

17 Jan '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1041?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1041: -------------------------------- Epic Link: OVIRT-400 > Base experimantal flow on transactional repos > --------------------------------------------- > > Key: OVIRT-1041 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1041 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Repositories Mgmt > Reporter: Barak Korren > Assignee: infra > Priority: High > > We recently seen various issues with the way the experimental repos are managed: > * The latest.tested repos is close to unusable because it changes very rapidly and does not keep history around > * Its impossible to have more then one experimental flow running in parallel because there can be only one latest.under_test repo > * We've seem various race conditions happening with the experimental repos because they are manipulated both by the 'deploy-to-experimental' jobs and by the 'test-repo' jobs. > * The experimental repo is manipulated by various secret and undocumented scripts in resources.ovirt.org. This makes things hard to debug. > * It is close to impossible to reproduce experimental runs because the exact repo used for those runs acn get destroyed as soon as the run is done > We've recently created the technology to maintain transactional mirrors (see OVIRT-575). It is desirable to use the same technique for managing the experimental repos. > Here is a breakdown of the steps to accomplish this task: > # The mirrors management script needs YUM repos to sync from. We can actually make each build_artifacts jobs generate its own mini repo by running 'createrepo' in 'exported-artifacts'. > # We need to make the 'deploy-to-experimental' job run the mirror management script to sync built artifacts into the relevant repo and create a snapshot. > # Once we have the above, we can treat the experimental repo just like any other repo in the OST reposync file. The same work that will be done to inject mirrors into the experimental flow can also inject the experimental repo snapshots. > # If we still want the experimental 'latest.tested' to be published on resources.ovirt.org, we can just 'reposync' it from the mirrors server once the OST run is successful. That published repo can include package and metadata history is it can be used by external consumers even if it changes frequently. -- This message was sent by Atlassian JIRA (v1000.695.1#100025)

1 0

[JIRA] (OVIRT-1040) ovirt-engine_4.1_check-patch-fc25-x86_64 build has failed
by eyal edri [Administrator] (oVirt JIRA) 17 Jan '17

17 Jan '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1040?page=com.atlassian.jira.… ] eyal edri [Administrator] updated OVIRT-1040: --------------------------------------------- Resolution: Cannot Reproduce Status: Done (was: To Do) > ovirt-engine_4.1_check-patch-fc25-x86_64 build has failed > --------------------------------------------------------- > > Key: OVIRT-1040 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1040 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Yevgeny Zaspitsky > Assignee: infra > > The $subject job [1] has failed upon a reason that doesn't seems to be > related to the patch it checks. > From the check_patch.sh.log: > [INFO] --- exec-maven-plugin:1.4.0:java (generate-enums-jaxb) @ > restapi-definition --- > SLF4J: Class path contains multiple SLF4J bindings. > SLF4J: Found binding in > [jar:file:/root/.m2/repository/org/slf4j/slf4j-log4j12/1.7.7/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: Found binding in > [jar:file:/root/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar!/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. > SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory] > [WARNING] > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:293) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at com.google.common.collect.AbstractMapBasedMultimap.wrapList(AbstractMapBasedMultimap.java:332) > at com.google.common.collect.AbstractMapBasedMultimap.wrapCollection(AbstractMapBasedMultimap.java:324) > at com.google.common.collect.AbstractMapBasedMultimap.get(AbstractMapBasedMultimap.java:308) > at com.google.common.collect.AbstractListMultimap.get(AbstractListMultimap.java:66) > at com.google.common.collect.ArrayListMultimap.get(ArrayListMultimap.java:66) > at org.jboss.weld.annotated.enhanced.jlr.EnhancedAnnotatedTypeImpl.getDeclaredEnhancedFields(EnhancedAnnotatedTypeImpl.java:427) > at org.jboss.weld.injection.InjectionPointFactory.getFieldInjectionPoints(InjectionPointFactory.java:210) > at org.jboss.weld.injection.producer.DefaultInjector.<init>(DefaultInjector.java:56) > at org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:58) > at org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49) > at org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:63) > at org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:47) > at org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:128) > at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87) > at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:100) > at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:80) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:261) > at org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:228) > at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78) > at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > ... 1 more > [WARNING] thread Thread[weld-worker-1,5,weld-workers] was interrupted > but is still alive after waiting at least 15000msecs > [WARNING] thread Thread[weld-worker-1,5,weld-workers] will linger > despite being asked to die via interruption > [WARNING] thread Thread[weld-worker-2,5,weld-workers] will linger > despite being asked to die via interruption > [WARNING] NOTE: 2 thread(s) did not finish despite being asked to via > interruption. This is not a problem with exec:java, it is a problem > with the running code. Although not serious, it should be remedied. > [WARNING] Couldn't destroy threadgroup > org.codehaus.mojo.exec.ExecJavaMojo$IsolatedThreadGroup[name=org.ovirt.api.metamodel.tool.Main,maxpri=10] > java.lang.IllegalThreadStateException > at java.lang.ThreadGroup.destroy(ThreadGroup.java:778) > at java.lang.ThreadGroup.destroy(ThreadGroup.java:795) > at org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:328) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) > at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > [1] - > http://jenkins.ovirt.org/job/ovirt-engine_4.1_check-patch-fc25-x86_64/281/ -- This message was sent by Atlassian JIRA (v1000.695.1#100025)

1 0

[JIRA] (OVIRT-1040) ovirt-engine_4.1_check-patch-fc25-x86_64 build has failed
by eyal edri [Administrator] (oVirt JIRA) 17 Jan '17

17 Jan '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1040?page=com.atlassian.jira.… ] eyal edri [Administrator] commented on OVIRT-1040: -------------------------------------------------- OK, I'm documenting that the slave was vm0050.workers-phx.ovirt.org so if we'll see more failures on that slave we'll take it offline. [~ederevea] fyi. > ovirt-engine_4.1_check-patch-fc25-x86_64 build has failed > --------------------------------------------------------- > > Key: OVIRT-1040 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1040 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Yevgeny Zaspitsky > Assignee: infra > > The $subject job [1] has failed upon a reason that doesn't seems to be > related to the patch it checks. > From the check_patch.sh.log: > [INFO] --- exec-maven-plugin:1.4.0:java (generate-enums-jaxb) @ > restapi-definition --- > SLF4J: Class path contains multiple SLF4J bindings. > SLF4J: Found binding in > [jar:file:/root/.m2/repository/org/slf4j/slf4j-log4j12/1.7.7/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: Found binding in > [jar:file:/root/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar!/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. > SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory] > [WARNING] > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:293) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at com.google.common.collect.AbstractMapBasedMultimap.wrapList(AbstractMapBasedMultimap.java:332) > at com.google.common.collect.AbstractMapBasedMultimap.wrapCollection(AbstractMapBasedMultimap.java:324) > at com.google.common.collect.AbstractMapBasedMultimap.get(AbstractMapBasedMultimap.java:308) > at com.google.common.collect.AbstractListMultimap.get(AbstractListMultimap.java:66) > at com.google.common.collect.ArrayListMultimap.get(ArrayListMultimap.java:66) > at org.jboss.weld.annotated.enhanced.jlr.EnhancedAnnotatedTypeImpl.getDeclaredEnhancedFields(EnhancedAnnotatedTypeImpl.java:427) > at org.jboss.weld.injection.InjectionPointFactory.getFieldInjectionPoints(InjectionPointFactory.java:210) > at org.jboss.weld.injection.producer.DefaultInjector.<init>(DefaultInjector.java:56) > at org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:58) > at org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49) > at org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:63) > at org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:47) > at org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:128) > at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87) > at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:100) > at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:80) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:261) > at org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:228) > at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78) > at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > ... 1 more > [WARNING] thread Thread[weld-worker-1,5,weld-workers] was interrupted > but is still alive after waiting at least 15000msecs > [WARNING] thread Thread[weld-worker-1,5,weld-workers] will linger > despite being asked to die via interruption > [WARNING] thread Thread[weld-worker-2,5,weld-workers] will linger > despite being asked to die via interruption > [WARNING] NOTE: 2 thread(s) did not finish despite being asked to via > interruption. This is not a problem with exec:java, it is a problem > with the running code. Although not serious, it should be remedied. > [WARNING] Couldn't destroy threadgroup > org.codehaus.mojo.exec.ExecJavaMojo$IsolatedThreadGroup[name=org.ovirt.api.metamodel.tool.Main,maxpri=10] > java.lang.IllegalThreadStateException > at java.lang.ThreadGroup.destroy(ThreadGroup.java:778) > at java.lang.ThreadGroup.destroy(ThreadGroup.java:795) > at org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:328) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) > at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > [1] - > http://jenkins.ovirt.org/job/ovirt-engine_4.1_check-patch-fc25-x86_64/281/ -- This message was sent by Atlassian JIRA (v1000.695.1#100025)

1 0