- Infra - oVirt List Archives

[CQ]: 6f46b0a (ovirt-ansible-disaster-recovery) failed "ovirt-master" system tests
by oVirt Jenkins 20 Jan '18

20 Jan '18

Change 6f46b0a (ovirt-ansible-disaster-recovery) is probably the reason behind recent system test failures in the "ovirt-master" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://github.com/oVirt/ovirt-ansible-disaster-recovery/commit/6f46b0a5f93… For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4990/

1 0

[JIRA] (OVIRT-1854) fc26 dashboard jobs failing on rpm install for cmake-data and cmake
by Greg Sheremeta (oVirt JIRA) 19 Jan '18

19 Jan '18

This is a multi-part message in MIME format... ------------=_1516387458-10915-112 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1854?page=com.atlassian.jira.… ] Greg Sheremeta commented on OVIRT-1854: --------------------------------------- It's happening locally with mock_runner too > fc26 dashboard jobs failing on rpm install for cmake-data and cmake > ------------------------------------------------------------------- > > Key: OVIRT-1854 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1854 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Greg Sheremeta > Assignee: infra > > Hi, > Anyone seen anything like this? > http://jenkins.ovirt.org/job/ovirt-engine-dashboard_master_check-merged-fc2… > 17:45:32 --> Processing Dependency: (cmake = 3.10.1-11.fc26 if cmake < > 3.10.1-11.fc26) for package: cmake-rpm-macros-3.10.1-11.fc26.noarch > 17:45:32 ---> Package device-mapper.x86_64 0:1.02.137-6.fc26 will be > installed > 17:45:32 --> Finished Dependency Resolution > 17:45:32 Error: Package: cmake-rpm-macros-3.10.1-11.fc26.noarch > (fedora-updates-fc26) > 17:45:32 Requires: (cmake-data = 3.10.1-11.fc26 if cmake-data < > 3.10.1-11.fc26) > 17:45:32 You could try using --skip-broken to work around the problem > 17:45:32 Error: Package: cmake-rpm-macros-3.10.1-11.fc26.noarch > (fedora-updates-fc26) > 17:45:32 Requires: (cmake = 3.10.1-11.fc26 if cmake < > 3.10.1-11.fc26) > 17:45:32 You could try running: rpm -Va --nofiles --nodigest > -- > GREG SHEREMETA > SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX > Red Hat NA > <https://www.redhat.com/> > gshereme(a)redhat.com IRC: gshereme > <https://red.ht/sig> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076) ------------=_1516387458-10915-112 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1854?page=com.atlassian.jira.… ]</pre> <h3>Greg Sheremeta commented on OVIRT-1854:</h3> <p>It's happening locally with mock_runner too</p> <blockquote><h3>fc26 dashboard jobs failing on rpm install for cmake-data and cmake</h3> <pre> Key: OVIRT-1854 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1854 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Greg Sheremeta Assignee: infra</pre> <p>Hi, Anyone seen anything like this? <a href="http://jenkins.ovirt.org/job/ovirt-engine-dashboard_master_check-merged-fc2…">http://jenkins.ovirt.org/job/ovirt-engine-dashboard_master_check-merged-fc2…</a> 17:45:32 --> Processing Dependency: (cmake = 3.10.1-11.fc26 if cmake < 3.10.1-11.fc26) for package: cmake-rpm-macros-3.10.1-11.fc26.noarch 17:45:32 ---> Package device-mapper.x86_64 0:1.02.137-6.fc26 will be installed 17:45:32 --> Finished Dependency Resolution 17:45:32 Error: Package: cmake-rpm-macros-3.10.1-11.fc26.noarch (fedora-updates-fc26) 17:45:32 Requires: (cmake-data = 3.10.1-11.fc26 if cmake-data < 3.10.1-11.fc26) 17:45:32 You could try using --skip-broken to work around the problem 17:45:32 Error: Package: cmake-rpm-macros-3.10.1-11.fc26.noarch (fedora-updates-fc26) 17:45:32 Requires: (cmake = 3.10.1-11.fc26 if cmake < 3.10.1-11.fc26) 17:45:32 You could try running: rpm -Va --nofiles --nodigest — GREG SHEREMETA SENIOR SOFTWARE ENGINEER – TEAM LEAD – RHV UX Red Hat NA <<a href="https://www.redhat.com/">https://www.redhat.com/</a>> gshereme(a)redhat.com IRC: gshereme <<a href="https://red.ht/sig">https://red.ht/sig</a>></p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1516387458-10915-112--

1 0

[JIRA] (OVIRT-1854) fc26 dashboard jobs failing on rpm install for cmake-data and cmake
by Greg Sheremeta (oVirt JIRA) 19 Jan '18

19 Jan '18

Greg Sheremeta created OVIRT-1854: ------------------------------------- Summary: fc26 dashboard jobs failing on rpm install for cmake-data and cmake Key: OVIRT-1854 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1854 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Greg Sheremeta Assignee: infra Hi, Anyone seen anything like this? http://jenkins.ovirt.org/job/ovirt-engine-dashboard_master_check-merged-fc2… 17:45:32 --> Processing Dependency: (cmake = 3.10.1-11.fc26 if cmake < 3.10.1-11.fc26) for package: cmake-rpm-macros-3.10.1-11.fc26.noarch 17:45:32 ---> Package device-mapper.x86_64 0:1.02.137-6.fc26 will be installed 17:45:32 --> Finished Dependency Resolution 17:45:32 Error: Package: cmake-rpm-macros-3.10.1-11.fc26.noarch (fedora-updates-fc26) 17:45:32 Requires: (cmake-data = 3.10.1-11.fc26 if cmake-data < 3.10.1-11.fc26) 17:45:32 You could try using --skip-broken to work around the problem 17:45:32 Error: Package: cmake-rpm-macros-3.10.1-11.fc26.noarch (fedora-updates-fc26) 17:45:32 Requires: (cmake = 3.10.1-11.fc26 if cmake < 3.10.1-11.fc26) 17:45:32 You could try running: rpm -Va --nofiles --nodigest -- GREG SHEREMETA SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX Red Hat NA <https://www.redhat.com/> gshereme(a)redhat.com IRC: gshereme <https://red.ht/sig> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)

1 0

[CQ]: 86590, 1 (ovirt-log-collector) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 19 Jan '18

19 Jan '18

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

1 0

[CQ]: 85968, 8 (vdsm) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 19 Jan '18

19 Jan '18

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

1 0

[CQ]: 86584, 1 (ovirt-log-collector) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 19 Jan '18

19 Jan '18

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

1 0

[CQ]: 86584, 1 (ovirt-log-collector) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 19 Jan '18

19 Jan '18

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

1 0

[CQ]: 86552,1 (ovirt-log-collector) failed "ovirt-4.2" system tests
by oVirt Jenkins 19 Jan '18

19 Jan '18

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

3 2

[oVirt Jenkins] standard-enqueue - Build #9053 - FAILURE!
by jenkins＠jenkins.phx.ovirt.org 19 Jan '18

19 Jan '18

------=_Part_176_977545164.1516374679815 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.ovirt.org/job/standard-enqueue/9053/ Build Name: #9053 Build Description: Gerrit: 86417 - ovirt-log-collector (master) Build Status: FAILURE Gerrit change: https://gerrit.ovirt.org/86417 - title: analyzer: Add IPTablesConfigSiteCustom pre-condition - project: ovirt-log-collector - branch: master - author: Ala Hino <ahino(a)redhat.com> ------=_Part_176_977545164.1516374679815--

1 0

[CQ]: 86582, 1 (ovirt-engine-dashboard) failed "ovirt-4.2" system tests
by oVirt Jenkins 19 Jan '18

19 Jan '18

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

1 0

[JIRA] (OVIRT-1849) enable all gerrit hooks for cockpit-ovirt project
by sbonazzo (oVirt JIRA) 19 Jan '18

19 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1849?page=com.atlassian.jira.… ] sbonazzo commented on OVIRT-1849: --------------------------------- I agree with [~rbarry] , let's enable all of them. > enable all gerrit hooks for cockpit-ovirt project > ------------------------------------------------- > > Key: OVIRT-1849 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1849 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: eyal edri > Assignee: infra > > It looks like the cockpit-ovirt project doesn't have all hooks enabled, current these are the hooks its using: > /home/gerrit2/review_site/hooks/custom_hooks/update_tracker > /home/gerrit2/review_site/hooks/custom_hooks/comment-added.propagate_review_values > If we want that the hooks will also update bz status and do other verification like backporing, we need to add more hooks. > [~sbonazzo(a)redhat.com] [~msivak(a)redhat.com] please comment which hooks you'd like to enable or all of them. > Info on the hooks can be found here :http://ovirt-infra-docs.readthedocs.io/en/latest/General/Creating_Gerrit_Projects/index.html#enabling-custom-gerrit-hooks > [~amarchuk] fyi -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)

1 0

[oVirt Jenkins] standard-enqueue - Build #9050 - FAILURE!
by jenkins＠jenkins.phx.ovirt.org 19 Jan '18

19 Jan '18

------=_Part_174_1590852078.1516372324082 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.ovirt.org/job/standard-enqueue/9050/ Build Name: #9050 Build Description: Gerrit: 86566 - ovirt-engine-dashboard (4.2) Build Status: FAILURE Gerrit change: https://gerrit.ovirt.org/86566 - title: Enable Czech (cs-CZ) as a supported locale, enhance normalize script - project: ovirt-engine-dashboard - branch: ovirt-engine-dashboard-1.2 - author: Scott Dickerson <sdickers(a)redhat.com> ------=_Part_174_1590852078.1516372324082--

1 0

Subject: [ OST Failure Report ] [ oVirt Master ] [ Jan 15th 2018 ] [ 006_migrations.migrate_vm ]
by Dafna Ron 19 Jan '18

19 Jan '18

Hi, We had a failure in test 006_migrations.migrate_vm <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4842/testRepo…>. the migration failed with reason "VMExists" Seems to be an issue which is caused by connectivity between engine and hosts. I remember this issue happening before a few weeks ago - is there a solution/bug for this issue? *Link and headline of suspected patches: https://gerrit.ovirt.org/#/c/86114/4 <https://gerrit.ovirt.org/#/c/86114/4> - net tests: Fix vlan creation name length in nettestlib Link to Job:* *http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4842/ <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4842/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4842/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4842/artifact/>(Relevant) error snippet from the log: <error>* *vdsm dst:2018-01-15 06:47:03,355-0500 ERROR (jsonrpc/0) [api] FINISH create error=Virtual machine already exists (api:124)Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 117, in method ret = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/API.py", line 180, in create raise exception.VMExists()VMExists: Virtual machine already exists* *vdsm src: 2018-01-15 06:47:03,359-0500 ERROR (migsrc/d17a2482) [virt.vm] *(vmId='d17a2482-4904-4cbc-8d13-3a3b7840782d') migration destination error: Virtual machine already exists (migration:290 *)* *Engine: 2018-01-15 06:45:30,169-05 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring] (EE-ManagedThreadFactory-engineScheduled-Thread-34) [] Failure to refresh host 'lago-basic-suite-master-host-0' runtime info: java.net.ConnectException: Connection refused2018-01-15 06:45:30,169-05 DEBUG [org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring] (EE-ManagedThreadFactory-engineScheduled-Thread-34) [] Exception: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException: java.net.ConnectException: Connection refused at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.createNetworkException(VdsBrokerCommand.java:159) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:122) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:73) [vdsbroker.jar:] at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:33) [dal.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.DefaultVdsCommandExecutor.execute(DefaultVdsCommandExecutor.java:14) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.ResourceManager.runVdsCommand(ResourceManager.java:387) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.ResourceManager$Proxy$_$$_WeldSubclass.runVdsCommand$$super(Unknown Source) [vdsbroker.jar:] at sun.reflect.GeneratedMethodAccessor234.invoke(Unknown Source) [:1.8.0_151] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_151] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_151] at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:49) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:77) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.ovirt.engine.core.common.di.interceptor.LoggingInterceptor.apply(LoggingInterceptor.java:12) [common.jar:] at sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source) [:1.8.0_151] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_151] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_151] at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.ovirt.engine.core.vdsbroker.ResourceManager$Proxy$_$$_WeldSubclass.runVdsCommand(Unknown Source) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsManager.refreshCapabilities(VdsManager.java:647) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring.refreshVdsRunTimeInfo(HostMonitoring.java:118) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring.refresh(HostMonitoring.java:85) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsManager.refresh(VdsManager.java:267) [vdsbroker.jar:] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_151] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [rt.jar:1.8.0_151] at org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.access$201(ManagedScheduledThreadPoolExecutor.java:383) [javax.enterprise.concurrent-1.0.jar:] at org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.run(ManagedScheduledThreadPoolExecutor.java:534) [javax.enterprise.concurrent-1.0.jar:] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_151] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_151] at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_151] at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250) [javax.enterprise.concurrent-1.0.jar:] at org.jboss.as.ee.concurrent.service.ElytronManagedThreadFactory$ElytronManagedThread.run(ElytronManagedThreadFactory.java:78)Caused by: java.net.ConnectException: Connection refused at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) [rt.jar:1.8.0_151] at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717) [rt.jar:1.8.0_151] at org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient.connect(ReactorClient.java:118) [vdsm-jsonrpc-java-client.jar:] at org.ovirt.vdsm.jsonrpc.client.JsonRpcClient.getClient(JsonRpcClient.java:160) [vdsm-jsonrpc-java-client.jar:] at org.ovirt.vdsm.jsonrpc.client.JsonRpcClient.call(JsonRpcClient.java:93) [vdsm-jsonrpc-java-client.jar:] at org.ovirt.engine.core.vdsbroker.jsonrpc.FutureMap.<init>(FutureMap.java:70) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.jsonrpc.JsonRpcVdsServer.getCapabilities(JsonRpcVdsServer.java:314) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand.executeVdsBrokerCommand(GetCapabilitiesVDSCommand.java:22) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:112) [vdsbroker.jar:] ... 34 more2018-01-15 06:45:30,170-05 DEBUG [org.ovirt.engine.core.vdsbroker.VdsManager] (EE-ManagedThreadFactory-engineScheduled-Thread-34) [] Failed to refresh VDS, network error, continuing, vds='lago-basic-suite-master-host-0'(31f09289-ec6c-42ff-a745-e82e8ac8e6b9): java.net.ConnectException: Connection refused* *</error>*

5 5

[oVirt Jenkins] standard-enqueue - Build #9047 - FAILURE!
by jenkins＠jenkins.phx.ovirt.org 19 Jan '18

19 Jan '18

------=_Part_172_1731335912.1516369630931 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.ovirt.org/job/standard-enqueue/9047/ Build Name: #9047 Build Description: Gerrit: 86429 - ovirt-engine (master) Build Status: FAILURE Gerrit change: https://gerrit.ovirt.org/86429 - title: ansible: Add posibility to specify verbose level - project: ovirt-engine - branch: master - author: Ondra Machacek <omachace(a)redhat.com> ------=_Part_172_1731335912.1516369630931--

1 0

[oVirt Jenkins] standard-enqueue - Build #9045 - FAILURE!
by jenkins＠jenkins.phx.ovirt.org 19 Jan '18

19 Jan '18

------=_Part_166_759236527.1516348500216 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.ovirt.org/job/standard-enqueue/9045/ Build Name: #9045 Build Description: Gerrit: 86396 - vdsm (master) Build Status: FAILURE Gerrit change: https://gerrit.ovirt.org/86396 - title: automation: Extract create_artifacts_repo helper - project: vdsm - branch: master - author: Nir Soffer <nsoffer(a)redhat.com> ------=_Part_166_759236527.1516348500216--

1 0

[CQ]: 86554, 1 (ovirt-log-collector) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 18 Jan '18

18 Jan '18

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

1 0

[CQ]: 86138, 6 (vdsm) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 18 Jan '18

18 Jan '18

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

1 0

[oVirt Jenkins] ovirt-system-tests_he-basic-suite-master - Build # 175 - Failure!
by jenkins＠jenkins.phx.ovirt.org 18 Jan '18

18 Jan '18

------=_Part_145_390858701.1516245236093 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/ Build: http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/175/ Build Number: 175 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #175 [Yedidyah Bar David] Revert "upgrade_suites: Update ovirt-engine-metrics" [Gal Ben Haim] ost: Fix Lago custom repo [Greg Sheremeta] ovirt-js-dependencies: add jobs for fc27, add 4.2 branch ----------------- Failed Tests: ----------------- No tests ran. ------=_Part_145_390858701.1516245236093--

1 1

[JIRA] (OVIRT-1853) gerrit hook adds patch to bug mentioned not in Bug-Url
by eyal edri (oVirt JIRA) 18 Jan '18

18 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1853?page=com.atlassian.jira.… ] eyal edri reassigned OVIRT-1853: -------------------------------- Assignee: Anton Marchukov (was: infra) > gerrit hook adds patch to bug mentioned not in Bug-Url > ------------------------------------------------------ > > Key: OVIRT-1853 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1853 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Yedidyah Bar David > Assignee: Anton Marchukov > > Hi, > I pushed [1], with a link to [2], and it was added there, even though > the link was not in 'Bug-Url:'. > [1] https://gerrit.ovirt.org/86530 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1535904 > -- > Didi -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)

1 0

[JIRA] (OVIRT-1853) gerrit hook adds patch to bug mentioned not in Bug-Url
by Yedidyah Bar David (oVirt JIRA) 18 Jan '18

18 Jan '18

Yedidyah Bar David created OVIRT-1853: ----------------------------------------- Summary: gerrit hook adds patch to bug mentioned not in Bug-Url Key: OVIRT-1853 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1853 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Yedidyah Bar David Assignee: infra Hi, I pushed [1], with a link to [2], and it was added there, even though the link was not in 'Bug-Url:'. [1] https://gerrit.ovirt.org/86530 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1535904 -- Didi -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)

1 0

[oVirt Jenkins] ovirt-node-ng_master_build-artifacts-el7-x86_64 - Build # 670 - Failure!
by jenkins＠jenkins.phx.ovirt.org 18 Jan '18

18 Jan '18

------=_Part_154_1136662867.1516272380235 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-node-ng_master_build-artifacts-el7-x86_6… Build: http://jenkins.ovirt.org/job/ovirt-node-ng_master_build-artifacts-el7-x86_6… Build Number: 670 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #670 [Yuval Turgeman] scripts: timeout when waiting for vm to install ----------------- Failed Tests: ----------------- No tests ran. ------=_Part_154_1136662867.1516272380235--

1 1

[CQ]: 86131, 7 (vdsm) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 18 Jan '18

18 Jan '18

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

1 0

[JIRA] (OVIRT-1852) Make change-queue handle continues steaks of failed patches together
by Barak Korren (oVirt JIRA) 18 Jan '18

18 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1852?page=com.atlassian.jira.… ] Barak Korren reassigned OVIRT-1852: ----------------------------------- Assignee: Barak Korren (was: infra) > Make change-queue handle continues steaks of failed patches together > -------------------------------------------------------------------- > > Key: OVIRT-1852 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1852 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Change Queue > Reporter: Barak Korren > Assignee: Barak Korren > > Lets assume we have a change queue testing projects 'a' and 'b' where patches had been submitted in the following order (from left to right): > a1 a2 a3 a4 b1 a5 > Lets further assume that a1 and b2 both introduced regressions to their respective projects, and a5 fixed the regression for project 'a'. > When running with all changes the CQ test will fail, and it will then run the bisection process testing the following sets of changes (where all tests will fail): > a1 a2 a3 > a1 <- a1 will be removed from the queue following this > a2 a3 a4 b1 a5 > a2 a3 > a2 <- a2 will be removed from the queue following this > a3 a4 b1 a5 > a3 a4 > a3 <- a3 will be removed from the queue following this > a4 b1 a5 > a4 <- a4 will be removed from the queue following this > b1 a5 > b1 <- b1 will be removed from the queue following this > a5 <- This run will finally succeed letting the build of 'a' go the 'tested'. > As we can see for the case described we will need 14 test runs to clear the queue and find a stable state. > We can optimize this using the fact that change queue can track individual projects as change streams, and furthermore, the queue knows in every point in time which change streams exhibited failure so far. What we can do is when calculating a bisection, check if the 1st change in the queue belongs to a know failing project, at this point test it individually rather then performing a bisection of the full queue. > With the starting conditions as described above, the sets of changes being tested would be: > a1 a2 a3 a4 b1 a5 > a1 a2 a3 <- We are starting a normal bisection here because at this point there is > not yet any knowledge about the failures in 'a' > a1 <- a1 will be removed and the failure in 'a' will be recorded > a2 a3 a4 b1 a5 > a2 <- Now the mechanism described above kicks in and a3 is tested alone > and removed > a3 a4 b1 a5 > a3 <- Same mechanism now causes a2 to be tested alone > a4 b1 a5 > a4 <- a4 will be removed from the queue following this > b1 a5 > b1 <- b1 will be removed from the queue following this > a5 <- This run will finally succeed letting the build of 'a' go the 'tested'. > So a total of 12 test runs - we save 2 test runs,. This can be significant in terms of time saving and more runs an be saved the more failing patches we have. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)

1 0

[JIRA] (OVIRT-1852) Make change-queue handle continues steaks of failed patches together
by Barak Korren (oVirt JIRA) 18 Jan '18

18 Jan '18

Barak Korren created OVIRT-1852: ----------------------------------- Summary: Make change-queue handle continues steaks of failed patches together Key: OVIRT-1852 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1852 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Change Queue Reporter: Barak Korren Assignee: infra Lets assume we have a change queue testing projects 'a' and 'b' where patches had been submitted in the following order (from left to right): a1 a2 a3 a4 b1 a5 Lets further assume that a1 and b2 both introduced regressions to their respective projects, and a5 fixed the regression for project 'a'. When running with all changes the CQ test will fail, and it will then run the bisection process testing the following sets of changes (where all tests will fail): a1 a2 a3 a1 <- a1 will be removed from the queue following this a2 a3 a4 b1 a5 a2 a3 a2 <- a2 will be removed from the queue following this a3 a4 b1 a5 a3 a4 a3 <- a3 will be removed from the queue following this a4 b1 a5 a4 <- a4 will be removed from the queue following this b1 a5 b1 <- b1 will be removed from the queue following this a5 <- This run will finally succeed letting the build of 'a' go the 'tested'. As we can see for the case described we will need 14 test runs to clear the queue and find a stable state. We can optimize this using the fact that change queue can track individual projects as change streams, and furthermore, the queue knows in every point in time which change streams exhibited failure so far. What we can do is when calculating a bisection, check if the 1st change in the queue belongs to a know failing project, at this point test it individually rather then performing a bisection of the full queue. With the starting conditions as described above, the sets of changes being tested would be: a1 a2 a3 a4 b1 a5 a1 a2 a3 <- We are starting a normal bisection here because at this point there is not yet any knowledge about the failures in 'a' a1 <- a1 will be removed and the failure in 'a' will be recorded a2 a3 a4 b1 a5 a2 <- Now the mechanism described above kicks in and a3 is tested alone and removed a3 a4 b1 a5 a3 <- Same mechanism now causes a2 to be tested alone a4 b1 a5 a4 <- a4 will be removed from the queue following this b1 a5 b1 <- b1 will be removed from the queue following this a5 <- This run will finally succeed letting the build of 'a' go the 'tested'. So a total of 12 test runs - we save 2 test runs,. This can be significant in terms of time saving and more runs an be saved the more failing patches we have. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)

1 0

[JIRA] (OVIRT-1852) Make change-queue handle continues steaks of failed patches together
by Barak Korren (oVirt JIRA) 18 Jan '18

18 Jan '18

This is a multi-part message in MIME format... ------------=_1516276894-19060-322 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1852?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1852: -------------------------------- Epic Link: OVIRT-400 > Make change-queue handle continues steaks of failed patches together > -------------------------------------------------------------------- > > Key: OVIRT-1852 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1852 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Change Queue > Reporter: Barak Korren > Assignee: infra > > Lets assume we have a change queue testing projects 'a' and 'b' where patches had been submitted in the following order (from left to right): > a1 a2 a3 a4 b1 a5 > Lets further assume that a1 and b2 both introduced regressions to their respective projects, and a5 fixed the regression for project 'a'. > When running with all changes the CQ test will fail, and it will then run the bisection process testing the following sets of changes (where all tests will fail): > a1 a2 a3 > a1 <- a1 will be removed from the queue following this > a2 a3 a4 b1 a5 > a2 a3 > a2 <- a2 will be removed from the queue following this > a3 a4 b1 a5 > a3 a4 > a3 <- a3 will be removed from the queue following this > a4 b1 a5 > a4 <- a4 will be removed from the queue following this > b1 a5 > b1 <- b1 will be removed from the queue following this > a5 <- This run will finally succeed letting the build of 'a' go the 'tested'. > As we can see for the case described we will need 14 test runs to clear the queue and find a stable state. > We can optimize this using the fact that change queue can track individual projects as change streams, and furthermore, the queue knows in every point in time which change streams exhibited failure so far. What we can do is when calculating a bisection, check if the 1st change in the queue belongs to a know failing project, at this point test it individually rather then performing a bisection of the full queue. > With the starting conditions as described above, the sets of changes being tested would be: > a1 a2 a3 a4 b1 a5 > a1 a2 a3 <- We are starting a normal bisection here because at this point there is > not yet any knowledge about the failures in 'a' > a1 <- a1 will be removed and the failure in 'a' will be recorded > a2 a3 a4 b1 a5 > a2 <- Now the mechanism described above kicks in and a3 is tested alone > and removed > a3 a4 b1 a5 > a3 <- Same mechanism now causes a2 to be tested alone > a4 b1 a5 > a4 <- a4 will be removed from the queue following this > b1 a5 > b1 <- b1 will be removed from the queue following this > a5 <- This run will finally succeed letting the build of 'a' go the 'tested'. > So a total of 12 test runs - we save 2 test runs,. This can be significant in terms of time saving and more runs an be saved the more failing patches we have. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076) ------------=_1516276894-19060-322 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1852?page=com.atlassian.jira.… ]</pre> <h3>Barak Korren updated OVIRT-1852:</h3> <pre>Epic Link: OVIRT-400</pre> <blockquote><h3>Make change-queue handle continues steaks of failed patches together</h3> <pre> Key: OVIRT-1852 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1852 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Change Queue Reporter: Barak Korren Assignee: infra</pre> <p>Lets assume we have a change queue testing projects ‘a’ and ‘b’ where patches had been submitted in the following order (from left to right): a1 a2 a3 a4 b1 a5 Lets further assume that a1 and b2 both introduced regressions to their respective projects, and a5 fixed the regression for project ‘a’. When running with all changes the CQ test will fail, and it will then run the bisection process testing the following sets of changes (where all tests will fail): a1 a2 a3 a1 <- a1 will be removed from the queue following this a2 a3 a4 b1 a5 a2 a3 a2 <- a2 will be removed from the queue following this a3 a4 b1 a5 a3 a4 a3 <- a3 will be removed from the queue following this a4 b1 a5 a4 <- a4 will be removed from the queue following this b1 a5 b1 <- b1 will be removed from the queue following this a5 <- This run will finally succeed letting the build of ‘a’ go the ‘tested’. As we can see for the case described we will need 14 test runs to clear the queue and find a stable state. We can optimize this using the fact that change queue can track individual projects as change streams, and furthermore, the queue knows in every point in time which change streams exhibited failure so far. What we can do is when calculating a bisection, check if the 1st change in the queue belongs to a know failing project, at this point test it individually rather then performing a bisection of the full queue. With the starting conditions as described above, the sets of changes being tested would be: a1 a2 a3 a4 b1 a5 a1 a2 a3 <- We are starting a normal bisection here because at this point there is</p> <pre>not yet any knowledge about the failures in 'a'</pre> <p>a1 <- a1 will be removed and the failure in ‘a’ will be recorded a2 a3 a4 b1 a5 a2 <- Now the mechanism described above kicks in and a3 is tested alone</p> <pre>and removed</pre> <p>a3 a4 b1 a5 a3 <- Same mechanism now causes a2 to be tested alone a4 b1 a5 a4 <- a4 will be removed from the queue following this b1 a5 b1 <- b1 will be removed from the queue following this a5 <- This run will finally succeed letting the build of ‘a’ go the ‘tested’. So a total of 12 test runs – we save 2 test runs,. This can be significant in terms of time saving and more runs an be saved the more failing patches we have.</p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1516276894-19060-322--

1 0

[JIRA] (OVIRT-1851) Make chaneg-queue throw-away not-building patches quickly
by Barak Korren (oVirt JIRA) 18 Jan '18

18 Jan '18

This is a multi-part message in MIME format... ------------=_1516275027-10230-333 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1851?page=com.atlassian.jira.… ] Barak Korren reassigned OVIRT-1851: ----------------------------------- Assignee: Barak Korren (was: infra) > Make chaneg-queue throw-away not-building patches quickly > --------------------------------------------------------- > > Key: OVIRT-1851 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1851 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Change Queue > Reporter: Barak Korren > Assignee: Barak Korren > > Currently test failures and build failures are treated the same by the check queue - in both cases the change queue runs a bisection to find out the change that caused the failure. > It the case of a build failure - it is possible to know immediately which patch failed to build, so we can remove it immediately from the queue and avoid some expensive bisection runs. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076) ------------=_1516275027-10230-333 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1851?page=com.atlassian.jira.… ]</pre> <h3>Barak Korren reassigned OVIRT-1851:</h3> <pre>Assignee: Barak Korren (was: infra)</pre> <blockquote><h3>Make chaneg-queue throw-away not-building patches quickly</h3> <pre> Key: OVIRT-1851 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1851 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Change Queue Reporter: Barak Korren Assignee: Barak Korren</pre> <p>Currently test failures and build failures are treated the same by the check queue – in both cases the change queue runs a bisection to find out the change that caused the failure. It the case of a build failure – it is possible to know immediately which patch failed to build, so we can remove it immediately from the queue and avoid some expensive bisection runs.</p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1516275027-10230-333--

1 0

[JIRA] (OVIRT-1851) Make chaneg-queue throw-away not-building patches quickly
by Barak Korren (oVirt JIRA) 18 Jan '18

18 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1851?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1851: -------------------------------- Epic Link: OVIRT-400 > Make chaneg-queue throw-away not-building patches quickly > --------------------------------------------------------- > > Key: OVIRT-1851 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1851 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Change Queue > Reporter: Barak Korren > Assignee: infra > > Currently test failures and build failures are treated the same by the check queue - in both cases the change queue runs a bisection to find out the change that caused the failure. > It the case of a build failure - it is possible to know immediately which patch failed to build, so we can remove it immediately from the queue and avoid some expensive bisection runs. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)

1 0

[JIRA] (OVIRT-1851) Make chaneg-queue throw-away not-building patches quickly
by Barak Korren (oVirt JIRA) 18 Jan '18

18 Jan '18

This is a multi-part message in MIME format... ------------=_1516275013-22664-382 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Barak Korren created OVIRT-1851: ----------------------------------- Summary: Make chaneg-queue throw-away not-building patches quickly Key: OVIRT-1851 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1851 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Change Queue Reporter: Barak Korren Assignee: infra Currently test failures and build failures are treated the same by the check queue - in both cases the change queue runs a bisection to find out the change that caused the failure. It the case of a build failure - it is possible to know immediately which patch failed to build, so we can remove it immediately from the queue and avoid some expensive bisection runs. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076) ------------=_1516275013-22664-382 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <h3>Barak Korren created OVIRT-1851:</h3> <pre> Summary: Make chaneg-queue throw-away not-building patches quickly Key: OVIRT-1851 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1851 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Change Queue Reporter: Barak Korren Assignee: infra</pre> <p>Currently test failures and build failures are treated the same by the check queue – in both cases the change queue runs a bisection to find out the change that caused the failure.</p> <p>It the case of a build failure – it is possible to know immediately which patch failed to build, so we can remove it immediately from the queue and avoid some expensive bisection runs.</p> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1516275013-22664-382--

1 0

[ OST Failure Report ] [ oVirt-Host ] [ 17-01-2018 ] [ 002_bootstrap.add_hosts ]
by Dafna Ron 18 Jan '18

18 Jan '18

Hi, We have a failure in test 002_bootstrap.add_hosts from upgrade suite. Can you please check the issue? *Link and headline of suspected patches: Reported as failed: https://gerrit.ovirt.org/#/c/86152/ <https://gerrit.ovirt.org/#/c/86152/> - build: post 4.2.1-1* *Reported as root cause: https://gerrit.ovirt.org/#/c/85421/ <https://gerrit.ovirt.org/#/c/85421/> - Require katello-agentLink to Job:* *http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4908/ <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4908/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4908/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4908/artifact>(Relevant) error snippet from the log: <error>nsaction commit.2018-01-17 00:08:41,743-05 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) [8f86c69] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), Installing Host lago-upgrade-from-release-suite-master-host0. Setting kernel arguments.2018-01-17 00:08:41,977-05 ERROR [org.ovirt.engine.core.uutils.ssh.SSHDialog] (EE-ManagedThreadFactory-engine-Thread-1) [8f86c69] Swallowing exception as preferring stderr2018-01-17 00:08:41,977-05 ERROR [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (VdsDeploy) [8f86c69] Error during deploy dialog2018-01-17 00:08:41,978-05 ERROR [org.ovirt.engine.core.uutils.ssh.SSHDialog] (EE-ManagedThreadFactory-engine-Thread-1) [8f86c69] SSH error running command root@lago-upgrade-from-release-suite-master-host0:'umask 0077; MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp -d -t ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; tar --warning=no-timestamp -C "${MYTMP}" -x && "${MYTMP}"/ovirt-host-deploy DIALOG/dialect=str:machine DIALOG/customization=bool:True': RuntimeException: Unexpected error during execution: bash: line 1: 1419 Segmentation fault "${MYTMP}"/ovirt-host-deploy DIALOG/dialect=str:machine DIALOG/customization=bool:True2018-01-17 00:08:41,979-05 ERROR [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (EE-ManagedThreadFactory-engine-Thread-1) [8f86c69] Error during host lago-upgrade-from-release-suite-master-host0 install2018-01-17 00:08:41,983-05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-1) [8f86c69] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An error has occurred during installation of Host lago-upgrade-from-release-suite-master-host0: Unexpected error during execution: bash: line 1: 1419 Segmentation fault "${MYTMP}"/ovirt-host-deploy DIALOG/dialect=str:machine DIALOG/customization=bool:True.2018-01-17 00:08:41,983-05 ERROR [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (EE-ManagedThreadFactory-engine-Thread-1) [8f86c69] Error during host lago-upgrade-from-release-suite-master-host0 install, preferring first exception: Unexpected connection termination2018-01-17 00:08:41,983-05 ERROR [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand] (EE-ManagedThreadFactory-engine-Thread-1) [8f86c69] Host installation failed for host '76f737a5-fc15-4641-91c8-f5ef28b02436', 'lago-upgrade-from-release-suite-master-host0': Unexpected connection termination2018-01-17 00:08:41,989-05 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (EE-ManagedThreadFactory-engine-Thread-1) [8f86c69] START, SetVdsStatusVDSCommand(HostName = lago-upgrade-from-release-suite-master-host0, SetVdsStatusVDSCommandParameters:{hostId='76f737a5-fc15-4641-91c8-f5ef28b02436', status='InstallFailed', nonOperationalReason='NONE', stopSpmFailureLogged='false', maintenanceReason='null'}), log id: 47ad9c872018-01-17 00:08:41,995-05 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (EE-ManagedThreadFactory-engine-Thread-1) [8f86c69] FINISH, SetVdsStatusVDSCommand, log id: 47ad9c872018-01-17 00:08:42,003-05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-1) [8f86c69] EVENT_ID: VDS_INSTALL_FAILED(505), Host lago-upgrade-from-release-suite-master-host0 installation failed. Unexpected connection termination.2018-01-17 00:08:42,014-05 INFO [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand] (EE-ManagedThreadFactory-engine-Thread-1) [8f86c69] Lock freed to object 'EngineLock:{exclusiveLocks='[76f737a5-fc15-4641-91c8-f5ef28b02436=VDS]', sharedLocks=''}'</error>*

2 1

ovirt-imageio is failing to build on fc27/fcraw
by Barak Korren 18 Jan '18

18 Jan '18

Hi Guys, I'm sure you are aware that 'ovirt-imageio' is currently failing to build on FC27 and Rawhide. I'm not sure you get the implications tough. The 1st thing that the release change-queue is checking, before running OST, is if all builds for all patches it is checking are building successfully for all platforms that the project has jobs for. This means that essentially no new 'ovirt-imageio' packages are making it into the tested and nightly repos for __any__ platform. Furthermore, with the way the system works for now, there is no special handling for build failures, with means they are treated like OST failures, which means the system runs an expensive bisection search to find the failing patch. So when your project fails to build, it slows down checking for other project's patches. I ask that you please do one of the following: 1. Fix the FC27 and RAWHIDE builds 2. Remove the FC27 and RAWHIDE build jobs 3. Turn the FC27 and RAWHIDE build jobs into check-merged jobs which are not checked by the change-queue. -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted

3 8

[JIRA] (OVIRT-1799) move project website to OpenShift v3
by Evgheni Dereveanchin (oVirt JIRA) 18 Jan '18

18 Jan '18

This is a multi-part message in MIME format... ------------=_1516270103-12367-245 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1799?page=com.atlassian.jira.… ] Evgheni Dereveanchin commented on OVIRT-1799: --------------------------------------------- I want to share a strange experience with Online v3. I have a personal account and yesterday I received an email of the following content: bq. Your access to OpenShift Online Starter was removed for account ***(a)gmail.com due to a prolonged period of inactivity. My account was removed along with the pods that were running at the point. There was no prior notice and the app I was using on a daily basis is now gone. So we should be really careful when migrating as the free tier seems to be very unreliable and have unclear terms of service. > move project website to OpenShift v3 > ------------------------------------ > > Key: OVIRT-1799 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1799 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Hosting > Reporter: Evgheni Dereveanchin > Assignee: infra > > After moving the website off OpenShift v2 in OVIRT-1624 we can now start thinking about how to host it on v3. We have an internal instance ready but ideally we should host the actual site outside PHX. > Opening this ticket to discuss the options -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076) ------------=_1516270103-12367-245 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1799?page=com.atlassian.jira.… ]</pre> <h3>Evgheni Dereveanchin commented on OVIRT-1799:</h3> <p>I want to share a strange experience with Online v3. I have a personal account and yesterday I received an email of the following content:</p> <p>bq. Your access to OpenShift Online Starter was removed for account ***(a)gmail.com due to a prolonged period of inactivity.</p> <p>My account was removed along with the pods that were running at the point. There was no prior notice and the app I was using on a daily basis is now gone. So we should be really careful when migrating as the free tier seems to be very unreliable and have unclear terms of service.</p> <blockquote><h3>move project website to OpenShift v3</h3> <pre> Key: OVIRT-1799 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1799 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Hosting Reporter: Evgheni Dereveanchin Assignee: infra</pre> <p>After moving the website off OpenShift v2 in OVIRT-1624 we can now start thinking about how to host it on v3. We have an internal instance ready but ideally we should host the actual site outside PHX. Opening this ticket to discuss the options</p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1516270103-12367-245--

1 0

Subject: [ OST Failure Report ] [ oVirt Master ] [Jan 15th 2018 ] [ 004_basic_sanity.verify_glance_import ]
by Dafna Ron 18 Jan '18

18 Jan '18

Hi, We had a failure in test : 004_basic_sanity.verify_glance_import <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4829/testRepo…> The issue is actually with engine loosing connection to host and assuming there was a failure. however, I could not find a failure in the vdsm which would be related to this issue. Please note that there is a NPE in the engine log for trying to update the task status which I think is something that should be addressed. *Link and headline of suspected patches: Patch repoted as the failed: https://gerrit.ovirt.org/#/c/86198/2 <https://gerrit.ovirt.org/#/c/86198/2>* Patch reported as root cause: https://gerrit.ovirt.org/#/c/84883/11 *Link to Job:* *http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4829/ <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4829/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4829/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4829/artifact/>(Relevant) error snippet from the log: <error>2018-01-14 21:24:16,881-05 ERROR [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for "6bae83f1-184c-475a-96e7-240e58ead94c"2018-01-14 21:25:34,824-05 INFO [org.ovirt.engine.core.bll.tasks.AsyncTaskManager] (default task-6) [ae77e2a8-1473-487d-949b-e6f525dcb38f] Adding task '388ef299-f83e-4af1-93a6-07781caf275f' (Parent Command 'AddImageFromScratch', Parameters Type 'org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters'), polling hasn't started yet..2018-01-14 21:25:34,866-05 INFO [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (default task-6) [ae77e2a8-1473-487d-949b-e6f525dcb38f] BaseAsyncTask::startPollingTask: Starting to poll task '388ef299-f83e-4af1-93a6-07781caf275f'.2018-01-14 21:25:34,900-05 ERROR [org.ovirt.engine.core.bll.storage.disk.AddDiskCommand] (default task-6) [ae77e2a8-1473-487d-949b-e6f525dcb38f] Command 'org.ovirt.engine.core.bll.storage.disk.AddDiskCommand' failed: null2018-01-14 21:25:34,900-05 ERROR [org.ovirt.engine.core.bll.storage.disk.AddDiskCommand] (default task-6) [ae77e2a8-1473-487d-949b-e6f525dcb38f] Exception: java.lang.NullPointerException at org.ovirt.engine.core.bll.VmCommand.executeCommand(VmCommand.java:163) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1140) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1282) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1931) [bll.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:164) [utils.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:103) [utils.jar:] at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1342) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:407) [bll.jar:] at org.ovirt.engine.core.bll.executor.DefaultBackendActionExecutor.execute(DefaultBackendActionExecutor.java:13) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:468) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:450) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:656) [bll.jar:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_151] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_151] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_151] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_151] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:78) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:88) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-11.0.0.Final.jar:11.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:255) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:381) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:244) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422):</error>*

2 1

[JIRA] (OVIRT-1850) rename he-basic to he-basic-noansible
by eyal edri (oVirt JIRA) 18 Jan '18

18 Jan '18

This is a multi-part message in MIME format... ------------=_1516266206-23853-339 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1850?page=com.atlassian.jira.… ] eyal edri commented on OVIRT-1850: ---------------------------------- Please send the relevant patches to OST to rename the suite as you wish, as the suite maintainer. As for [1], once [~gbenhaim(a)redhat.com] approves it there should be no issue merging it, worth also verifying with the manual job. > rename he-basic to he-basic-noansible > ------------------------------------- > > Key: OVIRT-1850 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1850 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Yedidyah Bar David > Assignee: infra > > Hi, > Hosted-engine setup recently moved to using the ansible flow by default [2]. > I pushed [1] to make he-basic use the old flow, so that we keep testing it. > Please merge [1], and rename 'he-basic' in the manual OST job to > 'he-basic-noansible'. Thanks. > [1] https://gerrit.ovirt.org/86398 > [2] https://gerrit.ovirt.org/83900 > -- > Didi -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076) ------------=_1516266206-23853-339 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1850?page=com.atlassian.jira.… ]</pre> <h3>eyal edri commented on OVIRT-1850:</h3> <p>Please send the relevant patches to OST to rename the suite as you wish, as the suite maintainer. As for [1], once [~gbenhaim(a)redhat.com] approves it there should be no issue merging it, worth also verifying with the manual job.</p> <blockquote><h3>rename he-basic to he-basic-noansible</h3> <pre> Key: OVIRT-1850 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1850 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Yedidyah Bar David Assignee: infra</pre> <p>Hi, Hosted-engine setup recently moved to using the ansible flow by default [2]. I pushed [1] to make he-basic use the old flow, so that we keep testing it. Please merge [1], and rename ‘he-basic’ in the manual OST job to ‘he-basic-noansible’. Thanks. [1] <a href="https://gerrit.ovirt.org/86398">https://gerrit.ovirt.org/86398</a> [2] <a href="https://gerrit.ovirt.org/83900">https://gerrit.ovirt.org/83900</a> — Didi</p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1516266206-23853-339--

1 0

[JIRA] (OVIRT-1850) rename he-basic to he-basic-noansible
by Yedidyah Bar David (oVirt JIRA) 18 Jan '18

18 Jan '18

This is a multi-part message in MIME format... ------------=_1516264295-14313-214 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Yedidyah Bar David created OVIRT-1850: ----------------------------------------- Summary: rename he-basic to he-basic-noansible Key: OVIRT-1850 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1850 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Yedidyah Bar David Assignee: infra Hi, Hosted-engine setup recently moved to using the ansible flow by default [2]. I pushed [1] to make he-basic use the old flow, so that we keep testing it. Please merge [1], and rename 'he-basic' in the manual OST job to 'he-basic-noansible'. Thanks. [1] https://gerrit.ovirt.org/86398 [2] https://gerrit.ovirt.org/83900 -- Didi -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076) ------------=_1516264295-14313-214 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <h3>Yedidyah Bar David created OVIRT-1850:</h3> <pre> Summary: rename he-basic to he-basic-noansible Key: OVIRT-1850 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1850 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Yedidyah Bar David Assignee: infra</pre> <p>Hi,</p> <p>Hosted-engine setup recently moved to using the ansible flow by default [2].</p> <p>I pushed [1] to make he-basic use the old flow, so that we keep testing it.</p> <p>Please merge [1], and rename ‘he-basic’ in the manual OST job to ‘he-basic-noansible’. Thanks.</p> <p>[1] <a href="https://gerrit.ovirt.org/86398">https://gerrit.ovirt.org/86398</a> [2] <a href="https://gerrit.ovirt.org/83900">https://gerrit.ovirt.org/83900</a> — Didi</p> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1516264295-14313-214--

1 0

[CQ]: 86118, 5 (vdsm) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 18 Jan '18

18 Jan '18

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

1 0

oVirt infra weekly meeting notes 17.01.2018
by Evgheni Dereveanchin 18 Jan '18

18 Jan '18

Hi everyone, Please find the topics of this week's infra meeting below: PHX DC: - CVE patching ongoing, most services are already patched, few hosts and VMs left - BIOS patching breaks lago on newer machines - to be fixed by lago team - Slave configuration being moved to global_setup OVIRT-1810 - Hardware refresh proposals for this year? - Add switches as we’re out of port - Would be great to have more bare metals -- Regards, Evgheni Dereveanchin

2 1

Build failed in Jenkins: system-sync_mirrors-centos-qemu-ev-release-el7-x86_64 #605
by jenkins＠jenkins.phx.ovirt.org 18 Jan '18

18 Jan '18

See <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-qemu-ev-release-el7…> ------------------------------------------ Started by timer [EnvInject] - Loading node environment variables. Building remotely on mirrors.phx.ovirt.org (mirrors) in workspace <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-qemu-ev-release-el7…> > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url http://gerrit.ovirt.org/jenkins.git # timeout=10 Cleaning workspace > git rev-parse --verify HEAD # timeout=10 Resetting working tree > git reset --hard # timeout=10 > git clean -fdx # timeout=10 Pruning obsolete local branches Fetching upstream changes from http://gerrit.ovirt.org/jenkins.git > git --version # timeout=10 > git fetch --tags --progress http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/* --prune > git rev-parse origin/master^{commit} # timeout=10 Checking out Revision 6d8b64bbd0be2a6dc477cece734b20b5a3875b45 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 6d8b64bbd0be2a6dc477cece734b20b5a3875b45 Commit message: "ovirt-js-dependencies: add jobs for fc27, add 4.2 branch" > git rev-list 6d8b64bbd0be2a6dc477cece734b20b5a3875b45 # timeout=10 [system-sync_mirrors-centos-qemu-ev-release-el7-x86_64] $ /bin/bash -xe /tmp/jenkins8743998934041441315.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror centos-qemu-ev-release-el7 x86_64 jenkins/data/mirrors-reposync.conf Checking if mirror needs a resync Traceback (most recent call last): File "/usr/bin/reposync", line 343, in <module> main() File "/usr/bin/reposync", line 175, in main my.doRepoSetup() File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 681, in doRepoSetup return self._getRepos(thisrepo, True) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 721, in _getRepos self._repos.doSetup(thisrepo) File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, in doSetup self.retrieveAllMD() File "/usr/lib/python2.7/site-packages/yum/repos.py", line 88, in retrieveAllMD dl = repo._async and repo._commonLoadRepoXML(repo) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1465, in _commonLoadRepoXML local = self.cachedir + '/repomd.xml' File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 774, in <lambda> cachedir = property(lambda self: self._dirGetAttr('cachedir')) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 757, in _dirGetAttr self.dirSetup() File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 735, in dirSetup self._dirSetupMkdir_p(dir) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 712, in _dirSetupMkdir_p raise Errors.RepoError, msg yum.Errors.RepoError: Error making cache directory: /home/jenkins/mirrors_cache/centos-qemu-ev-release-el7 error was: [Errno 17] File exists: '/home/jenkins/mirrors_cache/centos-qemu-ev-release-el7' Build step 'Execute shell' marked build as failure

1 1

[CQ]: 69848, 27 (vdsm) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 18 Jan '18

18 Jan '18

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

1 0

[CQ]: 74243, 9 (vdsm) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 18 Jan '18

18 Jan '18

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

1 0

[CQ]: 86261, 3 (vdsm) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 17 Jan '18

17 Jan '18

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

1 0

[ OST Failure Report ] [ oVirt-engine-dashboard ] [ 17-01-2018 ] [ 002_bootstrap.add_hosts ]
by Dafna Ron 17 Jan '18

17 Jan '18

hi, We are failing test 002_bootstrap.add_hosts <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4918/testRepo…> on ovirt-engine-dashboard in the upgrade suite. The error seems to be for missing metrics rules in the ansible playbook. *Link and headline of suspected patches: https://gerrit.ovirt.org/#/c/86318/ <https://gerrit.ovirt.org/#/c/86318/> - add fc27.spec link for automation Link to Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4918/ <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4918/>Link to all logs:* *http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4918/artifact/ <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4918/artifact/>(Relevant) error snippet from the log: <error>2018-01-17 08:36:23,706 p=27149 u=ovirt | Using /usr/share/ovirt-engine/playbooks/ansible.cfg as config file2018-01-17 08:36:23,734 p=27149 u=ovirt | ERROR! the role 'oVirt.metrics' was not found in /usr/share/ovirt-engine/playbooks/roles:/var/lib/ovirt-engine/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles:/usr/share/ovirt-engine/playbooks/roles:/usr/share/ovirt-engine/playbooksThe error appears to have been in '/usr/share/ovirt-engine/playbooks/roles/ovirt-host-deploy/meta/main.yml': line 6, column 5, but maybe elsewhere in the file depending on the exact syntax problem.The offending line appears to be: - ovirt-host-deploy-firewalld - oVirt.metrics ^ here2018-01-17 08:36:23,764-05 ERROR [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand] (EE-ManagedThreadFactory-engine-Thread-1) [849756c] Host installation failed for host '61c7b24f-e19d-4101-a945-a65b30b7b488', 'lago-upgrade-from-release-suite-master-host0': Failed to execute Ansible host-deploy role. Please check logs for more details: /var/log/ovirt-engine/host-deploy/ovirt-host-deploy-ansible-20180117083623-lago-upgrade-from-release-suite-master-host0-849756c.log2018-01-17 08:36:23,769-05 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (EE-ManagedThreadFactory-engine-Thread-1) [849756c] START, SetVdsStatusVDSCommand(HostName = lago-upgrade-from-release-suite-master-host0, SetVdsStatusVDSCommandParameters:{hostId='61c7b24f-e19d-4101-a945-a65b30b7b488', status='InstallFailed', nonOperationalReason='NONE', stopSpmFailureLogged='false', maintenanceReason='null'}), log id: 65b48a392018-01-17 08:36:23,773-05 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (EE-ManagedThreadFactory-engine-Thread-1) [849756c] FINISH, SetVdsStatusVDSCommand, log id: 65b48a392018-01-17 08:36:23,780-05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-1) [849756c] EVENT_ID: VDS_INSTALL_FAILED(505), Host lago-upgrade-from-release-suite-master-host0 installation failed. Failed to execute Ansible host-deploy role. Please check logs for more details: /var/log/ovirt-engine/host-deploy/ovirt-host-deploy-ansible-20180117083623-lago-upgrade-from-release-suite-master-host0-849756c.log.2018-01-17 08:36:23,788-05 INFO [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand] (EE-ManagedThreadFactory-engine-Thread-1) [849756c] Lock freed to object 'EngineLock:{exclusiveLocks='[61c7b24f-e19d-4101-a945-a65b30b7b488=VDS]', sharedLocks=''}'</error>*

3 2

[CQ]: 86318, 1 (ovirt-engine-dashboard) failed "ovirt-master" system tests
by oVirt Jenkins 17 Jan '18

17 Jan '18

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

1 0

Build failed in Jenkins: system-sync_mirrors-centos-updates-el7-x86_64 #1184
by jenkins＠jenkins.phx.ovirt.org 17 Jan '18

17 Jan '18

See <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-updates-el7-x86_64/…> Changes: [Gal Ben Haim] ost: Fix Lago custom repo [Greg Sheremeta] ovirt-js-dependencies: add jobs for fc27, add 4.2 branch ------------------------------------------ Started by timer [EnvInject] - Loading node environment variables. Building remotely on mirrors.phx.ovirt.org (mirrors) in workspace <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-updates-el7-x86_64/…> > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url http://gerrit.ovirt.org/jenkins.git # timeout=10 Cleaning workspace > git rev-parse --verify HEAD # timeout=10 Resetting working tree > git reset --hard # timeout=10 > git clean -fdx # timeout=10 Pruning obsolete local branches Fetching upstream changes from http://gerrit.ovirt.org/jenkins.git > git --version # timeout=10 > git fetch --tags --progress http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/* --prune > git rev-parse origin/master^{commit} # timeout=10 Checking out Revision 6d8b64bbd0be2a6dc477cece734b20b5a3875b45 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 6d8b64bbd0be2a6dc477cece734b20b5a3875b45 Commit message: "ovirt-js-dependencies: add jobs for fc27, add 4.2 branch" > git rev-list e55822b75080f700295d30c01ee5d5293799326c # timeout=10 [system-sync_mirrors-centos-updates-el7-x86_64] $ /bin/bash -xe /tmp/jenkins9162435330145680072.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror centos-updates-el7 x86_64 jenkins/data/mirrors-reposync.conf Checking if mirror needs a resync Traceback (most recent call last): File "/usr/bin/reposync", line 343, in <module> main() File "/usr/bin/reposync", line 175, in main my.doRepoSetup() File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 681, in doRepoSetup return self._getRepos(thisrepo, True) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 721, in _getRepos self._repos.doSetup(thisrepo) File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, in doSetup self.retrieveAllMD() File "/usr/lib/python2.7/site-packages/yum/repos.py", line 88, in retrieveAllMD dl = repo._async and repo._commonLoadRepoXML(repo) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1465, in _commonLoadRepoXML local = self.cachedir + '/repomd.xml' File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 774, in <lambda> cachedir = property(lambda self: self._dirGetAttr('cachedir')) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 757, in _dirGetAttr self.dirSetup() File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 735, in dirSetup self._dirSetupMkdir_p(dir) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 712, in _dirSetupMkdir_p raise Errors.RepoError, msg yum.Errors.RepoError: Error making cache directory: /home/jenkins/mirrors_cache/centos-updates-el7 error was: [Errno 17] File exists: '/home/jenkins/mirrors_cache/centos-updates-el7' Build step 'Execute shell' marked build as failure

1 1

[JIRA] (OVIRT-1849) enable all gerrit hooks for cockpit-ovirt project
by Ryan Barry (oVirt JIRA) 17 Jan '18

17 Jan '18

This is a multi-part message in MIME format... ------------=_1516193921-24843-123 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1849?page=com.atlassian.jira.… ] Ryan Barry commented on OVIRT-1849: ----------------------------------- I don't see a good reason not to enable all of them. At a minimum, set_modified would be great > enable all gerrit hooks for cockpit-ovirt project > ------------------------------------------------- > > Key: OVIRT-1849 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1849 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: eyal edri > Assignee: infra > > It looks like the cockpit-ovirt project doesn't have all hooks enabled, current these are the hooks its using: > /home/gerrit2/review_site/hooks/custom_hooks/update_tracker > /home/gerrit2/review_site/hooks/custom_hooks/comment-added.propagate_review_values > If we want that the hooks will also update bz status and do other verification like backporing, we need to add more hooks. > [~sbonazzo(a)redhat.com] [~msivak(a)redhat.com] please comment which hooks you'd like to enable or all of them. > Info on the hooks can be found here :http://ovirt-infra-docs.readthedocs.io/en/latest/General/Creating_Gerrit_Projects/index.html#enabling-custom-gerrit-hooks > [~amarchuk] fyi -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076) ------------=_1516193921-24843-123 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1849?page=com.atlassian.jira.… ]</pre> <h3>Ryan Barry commented on OVIRT-1849:</h3> <p>I don't see a good reason not to enable all of them.</p> <p>At a minimum, set_modified would be great</p> <blockquote><h3>enable all gerrit hooks for cockpit-ovirt project</h3> <pre> Key: OVIRT-1849 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1849 Project: oVirt - virtualization made easy Issue Type: Task Reporter: eyal edri Assignee: infra</pre> <p>It looks like the cockpit-ovirt project doesn't have all hooks enabled, current these are the hooks its using: /home/gerrit2/review_site/hooks/custom_hooks/update_tracker /home/gerrit2/review_site/hooks/custom_hooks/comment-added.propagate_review_values If we want that the hooks will also update bz status and do other verification like backporing, we need to add more hooks. [~sbonazzo(a)redhat.com] [~msivak(a)redhat.com] please comment which hooks you'd like to enable or all of them. Info on the hooks can be found here :<a href="http://ovirt-infra-docs.readthedocs.io/en/latest/General/Creating_Gerrit_Pr…">http://ovirt-infra-docs.readthedocs.io/en/latest/General/Creating_Gerrit_Pr…</a> [~amarchuk] fyi</p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1516193921-24843-123--

1 0

[JIRA] (OVIRT-1849) enable all gerrit hooks for cockpit-ovirt project
by Martin Sivak (oVirt JIRA) 17 Jan '18

17 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1849?page=com.atlassian.jira.… ] Martin Sivak commented on OVIRT-1849: ------------------------------------- I am not the maintainer, but we have to check all the sla bugs related to cockpit in depth as the status does not reflect the patches. [~rbarry] should give his opinion here too. > enable all gerrit hooks for cockpit-ovirt project > ------------------------------------------------- > > Key: OVIRT-1849 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1849 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: eyal edri > Assignee: infra > > It looks like the cockpit-ovirt project doesn't have all hooks enabled, current these are the hooks its using: > /home/gerrit2/review_site/hooks/custom_hooks/update_tracker > /home/gerrit2/review_site/hooks/custom_hooks/comment-added.propagate_review_values > If we want that the hooks will also update bz status and do other verification like backporing, we need to add more hooks. > [~sbonazzo(a)redhat.com] [~msivak(a)redhat.com] please comment which hooks you'd like to enable or all of them. > Info on the hooks can be found here :http://ovirt-infra-docs.readthedocs.io/en/latest/General/Creating_Gerrit_Projects/index.html#enabling-custom-gerrit-hooks > [~amarchuk] fyi -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)

1 0

[JIRA] (OVIRT-1849) enable all gerrit hooks for cockpit-ovirt project
by eyal edri (oVirt JIRA) 17 Jan '18

17 Jan '18

eyal edri created OVIRT-1849: -------------------------------- Summary: enable all gerrit hooks for cockpit-ovirt project Key: OVIRT-1849 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1849 Project: oVirt - virtualization made easy Issue Type: Task Reporter: eyal edri Assignee: infra It looks like the cockpit-ovirt project doesn't have all hooks enabled, current these are the hooks its using: /home/gerrit2/review_site/hooks/custom_hooks/update_tracker /home/gerrit2/review_site/hooks/custom_hooks/comment-added.propagate_review_values If we want that the hooks will also update bz status and do other verification like backporing, we need to add more hooks. [~sbonazzo(a)redhat.com] [~msivak(a)redhat.com] please comment which hooks you'd like to enable or all of them. Info on the hooks can be found here :http://ovirt-infra-docs.readthedocs.io/en/latest/General/Creating_Gerrit_Projects/index.html#enabling-custom-gerrit-hooks [~amarchuk] fyi -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)

1 0

[JIRA] (OVIRT-1849) enable all gerrit hooks for cockpit-ovirt project
by eyal edri (oVirt JIRA) 17 Jan '18

17 Jan '18

This is a multi-part message in MIME format... ------------=_1516189938-30836-1001 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1849?page=com.atlassian.jira.… ] eyal edri updated OVIRT-1849: ----------------------------- Epic Link: OVIRT-411 > enable all gerrit hooks for cockpit-ovirt project > ------------------------------------------------- > > Key: OVIRT-1849 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1849 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: eyal edri > Assignee: infra > > It looks like the cockpit-ovirt project doesn't have all hooks enabled, current these are the hooks its using: > /home/gerrit2/review_site/hooks/custom_hooks/update_tracker > /home/gerrit2/review_site/hooks/custom_hooks/comment-added.propagate_review_values > If we want that the hooks will also update bz status and do other verification like backporing, we need to add more hooks. > [~sbonazzo(a)redhat.com] [~msivak(a)redhat.com] please comment which hooks you'd like to enable or all of them. > Info on the hooks can be found here :http://ovirt-infra-docs.readthedocs.io/en/latest/General/Creating_Gerrit_Projects/index.html#enabling-custom-gerrit-hooks > [~amarchuk] fyi -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076) ------------=_1516189938-30836-1001 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1849?page=com.atlassian.jira.… ]</pre> <h3>eyal edri updated OVIRT-1849:</h3> <pre>Epic Link: OVIRT-411</pre> <blockquote><h3>enable all gerrit hooks for cockpit-ovirt project</h3> <pre> Key: OVIRT-1849 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1849 Project: oVirt - virtualization made easy Issue Type: Task Reporter: eyal edri Assignee: infra</pre> <p>It looks like the cockpit-ovirt project doesn't have all hooks enabled, current these are the hooks its using: /home/gerrit2/review_site/hooks/custom_hooks/update_tracker /home/gerrit2/review_site/hooks/custom_hooks/comment-added.propagate_review_values If we want that the hooks will also update bz status and do other verification like backporing, we need to add more hooks. [~sbonazzo(a)redhat.com] [~msivak(a)redhat.com] please comment which hooks you'd like to enable or all of them. Info on the hooks can be found here :<a href="http://ovirt-infra-docs.readthedocs.io/en/latest/General/Creating_Gerrit_Pr…">http://ovirt-infra-docs.readthedocs.io/en/latest/General/Creating_Gerrit_Pr…</a> [~amarchuk] fyi</p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100076)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1516189938-30836-1001--

1 0

[CQ]: 86152, 1 (ovirt-host) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 17 Jan '18

17 Jan '18

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

1 0

[vdsm][tag][master] Vdsm tagged: v4.20.14
by Francesco Romani 17 Jan '18

17 Jan '18

Hi infra, Hi infra, we have a new Vdsm tag on branch master for oVirt 4.2: tag v4.20.14 Tagger: Francesco Romani <fromani(a)redhat.com> Date: Wed Jan 17 10:07:06 2018 +0100 Vdsm 4.20.14 for oVirt 4.2.1 RC 3 commit a2074b0ff4537a8ea4a6de23acdc260b9a5658c7 +++ NOTE ABOUT BRANCHING: * We are merging again patches targeted for 4.2.1 on master * We don't yet have plans to branch out ovirt-4.2 from master. Following the usual Vdsm habit, we will branch out late, *after* Engine does. Bests, -- Francesco Romani Senior SW Eng., Virtualization R&D Red Hat IRC: fromani github: @fromanirh

1 0

Build failed in Jenkins: system-sync_mirrors-fedora-updates-fc27-x86_64 #168
by jenkins＠jenkins.phx.ovirt.org 17 Jan '18

17 Jan '18

See <http://jenkins.ovirt.org/job/system-sync_mirrors-fedora-updates-fc27-x86_64…> ------------------------------------------ Started by timer [EnvInject] - Loading node environment variables. Building remotely on mirrors.phx.ovirt.org (mirrors) in workspace <http://jenkins.ovirt.org/job/system-sync_mirrors-fedora-updates-fc27-x86_64…> > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url http://gerrit.ovirt.org/jenkins.git # timeout=10 Cleaning workspace > git rev-parse --verify HEAD # timeout=10 Resetting working tree > git reset --hard # timeout=10 > git clean -fdx # timeout=10 Pruning obsolete local branches Fetching upstream changes from http://gerrit.ovirt.org/jenkins.git > git --version # timeout=10 > git fetch --tags --progress http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/* --prune > git rev-parse origin/master^{commit} # timeout=10 Checking out Revision e55822b75080f700295d30c01ee5d5293799326c (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f e55822b75080f700295d30c01ee5d5293799326c Commit message: "Add line brak before mock_enable_network" > git rev-list e55822b75080f700295d30c01ee5d5293799326c # timeout=10 [system-sync_mirrors-fedora-updates-fc27-x86_64] $ /bin/bash -xe /tmp/jenkins7001290024257502171.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror fedora-updates-fc27 x86_64 jenkins/data/mirrors-reposync.conf Checking if mirror needs a resync Resyncing repo: fedora-updates-fc27 Syncing yum repo fedora-updates-fc27 for arch: x86_64 Traceback (most recent call last): File "/usr/bin/reposync", line 343, in <module> main() File "/usr/bin/reposync", line 175, in main my.doRepoSetup() File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 681, in doRepoSetup return self._getRepos(thisrepo, True) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 721, in _getRepos self._repos.doSetup(thisrepo) File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, in doSetup self.retrieveAllMD() File "/usr/lib/python2.7/site-packages/yum/repos.py", line 88, in retrieveAllMD dl = repo._async and repo._commonLoadRepoXML(repo) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1465, in _commonLoadRepoXML local = self.cachedir + '/repomd.xml' File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 774, in <lambda> cachedir = property(lambda self: self._dirGetAttr('cachedir')) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 757, in _dirGetAttr self.dirSetup() File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 735, in dirSetup self._dirSetupMkdir_p(dir) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 712, in _dirSetupMkdir_p raise Errors.RepoError, msg yum.Errors.RepoError: Error making cache directory: /home/jenkins/mirrors_cache/centos-qemu-ev-release-el7 error was: [Errno 17] File exists: '/home/jenkins/mirrors_cache/centos-qemu-ev-release-el7' Build step 'Execute shell' marked build as failure

1 1