Jenkins build is back to normal : ovirt_master_system-tests #857

[jenkins]

See 

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

oVirt infra daily report - unstable production jobs - 158

[jenkins]

Good morning!

Attached is the HTML page with the jenkins status report. You can see it also 
here:
 - 
http://jenkins.ovirt.org/job/system_jenkins-report/158//artifact/exported-artifacts/upstream_report.html

Cheers,
Jenkins

 
 
 
 RHEVM CI Jenkins Daily Report - 04/12/2016
 
00 Unstable Jobs (Production)
 
   
   cockpit-ovirt_ovirt-4.1_build-artifacts-fc23-x86_64
   
   This job is automatically updated by jenkins job builder, any manual
change will be lost in the next update. If you want to make permanent
changes, check out the 
jenkins repo.

   
   
   
   fabric-ovirt_master_check-merged-el7-x86_64
   
   This job is automatically updated by jenkins job builder, any manual
change will be lost in the next update. If you want to make permanent
changes, check out the 
jenkins repo.

   
   
   
   ovirt-engine-api-explorer_master_build-artifacts-fc23-x86_64
   
   This job is automatically updated by jenkins job builder, any manual
change will be lost in the next update. If you want to make permanent
changes, check out the 
jenkins repo.

   
   
   
   ovirt-guest-agent_master_build-artifacts-fc23-x86_64
   
   This job is automatically updated by jenkins job builder, any manual
change will be lost in the next update. If you want to make permanent
changes, check out the 
jenkins repo.

   
   
   
   ovirt-hosted-engine-ha_master_build-artifacts-el7-x86_64
   
   This job is automatically updated by jenkins job builder, any manual
change will be lost in the next update. If you want to make permanent
changes, check out the 
jenkins repo.

   
   
   
   ovirt-hosted-engine-ha_master_build-artifacts-fc24-x86_64
   
   This job is automatically updated by jenkins job builder, any manual
change will be lost in the next update. If you want to make permanent
changes, check out the 
jenkins repo.

   
   
   
   ovirt-live_master_create-iso-el7-x86_64
   
   This job generates a nightly iso of ovirt-live 

   
   
   
   ovirt-live_master_experimental_create-iso-el7-x86_64
   
   This job generates a nightly iso of ovirt-live using experimental repos

   
   
   
   ovirt-node-ng_master_build-artifacts-el7-x86_64
   
   This job is automatically updated by jenkins job builder, any manual
change will be lost in the next update. If you want to make permanent
changes, check out the 
jenkins repo.

   
   
   
   ovirt-node-ng_ovirt-3.6_build-artifacts-el7-x86_64
   
   This job is automatically updated by jenkins job builder, any manual
change will be lost in the next update. If you want to make permanent
changes, check out the 
jenkins repo.

   
   
   
   ovirt-node-ng_ovirt-4.0_build-artifacts-el7-x86_64
   
   This job is automatically updated by jenkins job builder, any manual
change will be lost in the next update. If you want to make permanent
changes, check out the 
jenkins repo.

   
   
   
   ovirt-node-ng_ovirt-4.1-pre_build-artifacts-el7-x86_64
   
   This job is automatically updated by jenkins job builder, any manual
change will be lost in the next update. If you want to make permanent
changes, check out the 
jenkins repo.

   
   
   
   ovirt-node-ng_ovirt-master-experimental_build-artifacts-el7-x86_64
   
   This job is automatically updated by jenkins job builder, any manual
change will be lost in the next update. If you want to make permanent
changes, check out the 
jenkins repo.

   
   
   
   ovirt-node_ovirt-3.6_create-iso-el7_merged
   
   This job is 

Re: Vdsm tests are 4X times faster on travis

[Nir Soffer]

On Sun, Dec 4, 2016 at 11:56 PM, Nir Soffer  wrote:
> On Sun, Dec 4, 2016 at 1:35 PM, Barak Korren  wrote:
>>> To debug this we need to get a shell on a jenkins slave with the exact
>>> environment of
>>> a running job.
>>
>> Perhaps try to check if this reproduces with mock_runner.sh.
>>
>> You can try running with with something like:
>>
>> JENKINS=
>> cd 
>> $JENKINS/mock_configs/mock_runner.sh --patch-only \
>>   --mock-confs-dir $JENKINS/mock_configs "fc24.*x86_64"
>
> I could reproduce this issue locally.
>
> Turns out that it was faulty test timeout code in vdsm test runner. We did not
> terminate a sleep child process when the tests finished, and mock was waiting
> until the sleep child process terminated.
>
> This patch should fix the issue:
> https://gerrit.ovirt.org/67799
>
> Here are successful builds:
> - 
> http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/5765/console
> - http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/4155/console
>
> Note that these builds include also make rpm and install check, since the 
> patch
> changed a makefile. This takes about 2 minutes but most patches do not trigger
> this check.

Here are builds that do not change the build system:
- http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/5767/console:
10:07
- http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/4157/console:
10:16

So we about 2X times faster now.

Nir
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Vdsm tests are 4X times faster on travis

[Nir Soffer]

On Sun, Dec 4, 2016 at 1:35 PM, Barak Korren  wrote:
>> To debug this we need to get a shell on a jenkins slave with the exact
>> environment of
>> a running job.
>
> Perhaps try to check if this reproduces with mock_runner.sh.
>
> You can try running with with something like:
>
> JENKINS=
> cd 
> $JENKINS/mock_configs/mock_runner.sh --patch-only \
>   --mock-confs-dir $JENKINS/mock_configs "fc24.*x86_64"

I could reproduce this issue locally.

Turns out that it was faulty test timeout code in vdsm test runner. We did not
terminate a sleep child process when the tests finished, and mock was waiting
until the sleep child process terminated.

This patch should fix the issue:
https://gerrit.ovirt.org/67799

Here are successful builds:
- http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/5765/console
- http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/4155/console

Note that these builds include also make rpm and install check, since the patch
changed a makefile. This takes about 2 minutes but most patches do not trigger
this check.

Nir
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [ovirt-devel] Experimental Flow for Master Fails to Run a VM

[Yaniv Kaul]

On Dec 4, 2016 10:57 PM, "Eyal Edri"  wrote:

tests are back to stable,  but with a cost of not testing 4.1 CL.


DC level.
But we are not explicitly using any of the 4.1 features for the time being.
(I'd like to believe implictly we did, qcow2v3 for example).


Iets hope we get centos 7.3 soon.


Indeed -  but we also need virt-builder image for it.
Y.


On Dec 4, 2016 22:41, "Yaniv Kaul"  wrote:

>
>
> On Dec 4, 2016 6:42 PM, "Arik Hadas"  wrote:
>
> Yaniv will try to lower the cluster level used in the system-tests to 4.0
> - this is supposed to solve the issue.
>
>
> Done.
> Y.
>
> If it won't help (we will know it in about an hour), we'll add a db-script
> that changes the rng device of the blank template only.
>
> On Sun, Dec 4, 2016 at 3:34 PM, Eyal Edri  wrote:
>
>> FYI,
>>
>> I opened a bug [1] to track this issue since I don't see any attempts to
>> resolve the issue on the thread, hopefully a bug will get more attention.
>> Opened on VDSM since we see the libvirt error there, feel free to move
>> product/team.
>>
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1401303
>>
>> On Sun, Dec 4, 2016 at 1:23 PM, Eyal Edri  wrote:
>>
>>> Not sure if relevant, but Juan posted a fix for SDK4 last time it
>>> happened ( but different failure on log-collector ):
>>>
>>> https://gerrit.ovirt.org/#/c/67213/
>>>
>>> * Added `urandom` to the `RngSource` enumerated type.
>>>
>>> On Sun, Dec 4, 2016 at 9:17 AM, Eyal Edri  wrote:
>>>
 And its still failing from Friday,
 Since we don't have official Centos 7.3 repos yet ( hopefully we'll
 have it this week, but as of this moment its not published yet ) , we have
 to either revert the offending patch
 or send a quick fix.

 Right now all experimental flows for master are not working and nightly
 rpms are not refreshed with new RPMs.



 On Fri, Dec 2, 2016 at 9:41 PM, Yaniv Kaul  wrote:

>
>
> On Dec 2, 2016 2:11 PM, "Anton Marchukov"  wrote:
>
> Hello Martin.
>
> Do by outdated you mean the old libvirt? If so that is that livirt
> available in CentOS 7.2? There is no 7.3 yet.
>
>
> Right, this is the issue.
> Y.
>
>
> Anton.
>
> On Fri, Dec 2, 2016 at 1:07 PM, Martin Polednik 
> wrote:
>
>> On 02/12/16 10:55 +0100, Anton Marchukov wrote:
>>
>>> Hello All.
>>>
>>> Engine log can be viewed here:
>>>
>>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_ma
>>> ster/3838/artifact/exported-artifacts/basic_suite_master.sh-
>>> el7/exported-artifacts/test_logs/basic-suite-master/post-004
>>> _basic_sanity.py/lago-basic-suite-master-engine/_var_log_ovi
>>> rt-engine/engine.log
>>>
>>> I see the following exception there:
>>>
>>> 2016-12-02 04:29:24,030-05 DEBUG
>>> [org.ovirt.vdsm.jsonrpc.client.internal.ResponseWorker]
>>> (ResponseWorker) [83b6b5d] Message received: {"jsonrpc": "2.0", "id":
>>> "ec254aad-441b-47e7-a644-aebddcc1d62c", "result": true}
>>> 2016-12-02 04:29:24,030-05 ERROR
>>> [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker)
>>> [83b6b5d] Not able to update response for
>>> "ec254aad-441b-47e7-a644-aebddcc1d62c"
>>> 2016-12-02 04:29:24,041-05 DEBUG
>>> [org.ovirt.engine.core.utils.timer.FixedDelayJobListener]
>>> (DefaultQuartzScheduler3) [47a31d72] Rescheduling
>>> DEFAULT.org.ovirt.engine.core.bll.gluster.GlusterSyncJob.ref
>>> reshLightWeightData#-9223372036854775775
>>> as there is no unfired trigger.
>>> 2016-12-02 04:29:24,024-05 DEBUG
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default
>>> task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] Exception:
>>> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException:
>>> VDSGenericException: VDSNetworkException: Timeout during xml-rpc call
>>> at org.ovirt.engine.core.vdsbroke
>>> r.vdsbroker.FutureVDSCommand.get(FutureVDSCommand.java:73)
>>> [vdsbroker.jar:]
>>>
>>> ...
>>>
>>> 2016-12-02 04:29:24,042-05 ERROR
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default
>>> task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] Timeout waiting for
>>> VDSM response: Internal timeout occured
>>> 2016-12-02 04:29:24,044-05 DEBUG
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVD
>>> SCommand]
>>> (default task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] START,
>>> GetCapabilitiesVDSCommand(HostName = lago-basic-suite-master-host0,
>>> VdsIdAndVdsVDSCommandParametersBase:{runAsync='true',
>>> hostId='5eb7019e-28a3-4f93-9188-685b6c64a2f5',
>>> vds='Host[lago-basic-suite-master-host0,5eb7019e-28a3-4f93-9
>>> 188-685b6c64a2f5]'}),
>>> 

Re: [ovirt-devel] Experimental Flow for Master Fails to Run a VM

[Eyal Edri]

tests are back to stable,  but with a cost of not testing 4.1 CL.

Iets hope we get centos 7.3 soon.

On Dec 4, 2016 22:41, "Yaniv Kaul"  wrote:

>
>
> On Dec 4, 2016 6:42 PM, "Arik Hadas"  wrote:
>
> Yaniv will try to lower the cluster level used in the system-tests to 4.0
> - this is supposed to solve the issue.
>
>
> Done.
> Y.
>
> If it won't help (we will know it in about an hour), we'll add a db-script
> that changes the rng device of the blank template only.
>
> On Sun, Dec 4, 2016 at 3:34 PM, Eyal Edri  wrote:
>
>> FYI,
>>
>> I opened a bug [1] to track this issue since I don't see any attempts to
>> resolve the issue on the thread, hopefully a bug will get more attention.
>> Opened on VDSM since we see the libvirt error there, feel free to move
>> product/team.
>>
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1401303
>>
>> On Sun, Dec 4, 2016 at 1:23 PM, Eyal Edri  wrote:
>>
>>> Not sure if relevant, but Juan posted a fix for SDK4 last time it
>>> happened ( but different failure on log-collector ):
>>>
>>> https://gerrit.ovirt.org/#/c/67213/
>>>
>>> * Added `urandom` to the `RngSource` enumerated type.
>>>
>>> On Sun, Dec 4, 2016 at 9:17 AM, Eyal Edri  wrote:
>>>
 And its still failing from Friday,
 Since we don't have official Centos 7.3 repos yet ( hopefully we'll
 have it this week, but as of this moment its not published yet ) , we have
 to either revert the offending patch
 or send a quick fix.

 Right now all experimental flows for master are not working and nightly
 rpms are not refreshed with new RPMs.



 On Fri, Dec 2, 2016 at 9:41 PM, Yaniv Kaul  wrote:

>
>
> On Dec 2, 2016 2:11 PM, "Anton Marchukov"  wrote:
>
> Hello Martin.
>
> Do by outdated you mean the old libvirt? If so that is that livirt
> available in CentOS 7.2? There is no 7.3 yet.
>
>
> Right, this is the issue.
> Y.
>
>
> Anton.
>
> On Fri, Dec 2, 2016 at 1:07 PM, Martin Polednik 
> wrote:
>
>> On 02/12/16 10:55 +0100, Anton Marchukov wrote:
>>
>>> Hello All.
>>>
>>> Engine log can be viewed here:
>>>
>>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_ma
>>> ster/3838/artifact/exported-artifacts/basic_suite_master.sh-
>>> el7/exported-artifacts/test_logs/basic-suite-master/post-004
>>> _basic_sanity.py/lago-basic-suite-master-engine/_var_log_ovi
>>> rt-engine/engine.log
>>>
>>> I see the following exception there:
>>>
>>> 2016-12-02 04:29:24,030-05 DEBUG
>>> [org.ovirt.vdsm.jsonrpc.client.internal.ResponseWorker]
>>> (ResponseWorker) [83b6b5d] Message received: {"jsonrpc": "2.0", "id":
>>> "ec254aad-441b-47e7-a644-aebddcc1d62c", "result": true}
>>> 2016-12-02 04:29:24,030-05 ERROR
>>> [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker)
>>> [83b6b5d] Not able to update response for
>>> "ec254aad-441b-47e7-a644-aebddcc1d62c"
>>> 2016-12-02 04:29:24,041-05 DEBUG
>>> [org.ovirt.engine.core.utils.timer.FixedDelayJobListener]
>>> (DefaultQuartzScheduler3) [47a31d72] Rescheduling
>>> DEFAULT.org.ovirt.engine.core.bll.gluster.GlusterSyncJob.ref
>>> reshLightWeightData#-9223372036854775775
>>> as there is no unfired trigger.
>>> 2016-12-02 04:29:24,024-05 DEBUG
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default
>>> task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] Exception:
>>> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException:
>>> VDSGenericException: VDSNetworkException: Timeout during xml-rpc call
>>> at org.ovirt.engine.core.vdsbroke
>>> r.vdsbroker.FutureVDSCommand.get(FutureVDSCommand.java:73)
>>> [vdsbroker.jar:]
>>>
>>> ...
>>>
>>> 2016-12-02 04:29:24,042-05 ERROR
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default
>>> task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] Timeout waiting for
>>> VDSM response: Internal timeout occured
>>> 2016-12-02 04:29:24,044-05 DEBUG
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVD
>>> SCommand]
>>> (default task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] START,
>>> GetCapabilitiesVDSCommand(HostName = lago-basic-suite-master-host0,
>>> VdsIdAndVdsVDSCommandParametersBase:{runAsync='true',
>>> hostId='5eb7019e-28a3-4f93-9188-685b6c64a2f5',
>>> vds='Host[lago-basic-suite-master-host0,5eb7019e-28a3-4f93-9
>>> 188-685b6c64a2f5]'}),
>>> log id: 58f448b8
>>> 2016-12-02 04:29:24,044-05 DEBUG
>>> [org.ovirt.vdsm.jsonrpc.client.reactors.stomp.impl.Message] (default
>>> task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] SEND
>>> destination:jms.topic.vdsm_requests
>>> 

Re: [ovirt-devel] Experimental Flow for Master Fails to Run a VM

[Yaniv Kaul]

On Dec 4, 2016 6:42 PM, "Arik Hadas"  wrote:

Yaniv will try to lower the cluster level used in the system-tests to 4.0 -
this is supposed to solve the issue.


Done.
Y.

If it won't help (we will know it in about an hour), we'll add a db-script
that changes the rng device of the blank template only.

On Sun, Dec 4, 2016 at 3:34 PM, Eyal Edri  wrote:

> FYI,
>
> I opened a bug [1] to track this issue since I don't see any attempts to
> resolve the issue on the thread, hopefully a bug will get more attention.
> Opened on VDSM since we see the libvirt error there, feel free to move
> product/team.
>
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1401303
>
> On Sun, Dec 4, 2016 at 1:23 PM, Eyal Edri  wrote:
>
>> Not sure if relevant, but Juan posted a fix for SDK4 last time it
>> happened ( but different failure on log-collector ):
>>
>> https://gerrit.ovirt.org/#/c/67213/
>>
>> * Added `urandom` to the `RngSource` enumerated type.
>>
>> On Sun, Dec 4, 2016 at 9:17 AM, Eyal Edri  wrote:
>>
>>> And its still failing from Friday,
>>> Since we don't have official Centos 7.3 repos yet ( hopefully we'll have
>>> it this week, but as of this moment its not published yet ) , we have to
>>> either revert the offending patch
>>> or send a quick fix.
>>>
>>> Right now all experimental flows for master are not working and nightly
>>> rpms are not refreshed with new RPMs.
>>>
>>>
>>>
>>> On Fri, Dec 2, 2016 at 9:41 PM, Yaniv Kaul  wrote:
>>>


 On Dec 2, 2016 2:11 PM, "Anton Marchukov"  wrote:

 Hello Martin.

 Do by outdated you mean the old libvirt? If so that is that livirt
 available in CentOS 7.2? There is no 7.3 yet.


 Right, this is the issue.
 Y.


 Anton.

 On Fri, Dec 2, 2016 at 1:07 PM, Martin Polednik 
 wrote:

> On 02/12/16 10:55 +0100, Anton Marchukov wrote:
>
>> Hello All.
>>
>> Engine log can be viewed here:
>>
>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_ma
>> ster/3838/artifact/exported-artifacts/basic_suite_master.sh-
>> el7/exported-artifacts/test_logs/basic-suite-master/post-004
>> _basic_sanity.py/lago-basic-suite-master-engine/_var_log_ovi
>> rt-engine/engine.log
>>
>> I see the following exception there:
>>
>> 2016-12-02 04:29:24,030-05 DEBUG
>> [org.ovirt.vdsm.jsonrpc.client.internal.ResponseWorker]
>> (ResponseWorker) [83b6b5d] Message received: {"jsonrpc": "2.0", "id":
>> "ec254aad-441b-47e7-a644-aebddcc1d62c", "result": true}
>> 2016-12-02 04:29:24,030-05 ERROR
>> [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker)
>> [83b6b5d] Not able to update response for
>> "ec254aad-441b-47e7-a644-aebddcc1d62c"
>> 2016-12-02 04:29:24,041-05 DEBUG
>> [org.ovirt.engine.core.utils.timer.FixedDelayJobListener]
>> (DefaultQuartzScheduler3) [47a31d72] Rescheduling
>> DEFAULT.org.ovirt.engine.core.bll.gluster.GlusterSyncJob.ref
>> reshLightWeightData#-9223372036854775775
>> as there is no unfired trigger.
>> 2016-12-02 04:29:24,024-05 DEBUG
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default
>> task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] Exception:
>> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException:
>> VDSGenericException: VDSNetworkException: Timeout during xml-rpc call
>> at org.ovirt.engine.core.vdsbroke
>> r.vdsbroker.FutureVDSCommand.get(FutureVDSCommand.java:73)
>> [vdsbroker.jar:]
>>
>> ...
>>
>> 2016-12-02 04:29:24,042-05 ERROR
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default
>> task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] Timeout waiting for
>> VDSM response: Internal timeout occured
>> 2016-12-02 04:29:24,044-05 DEBUG
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand]
>> (default task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] START,
>> GetCapabilitiesVDSCommand(HostName = lago-basic-suite-master-host0,
>> VdsIdAndVdsVDSCommandParametersBase:{runAsync='true',
>> hostId='5eb7019e-28a3-4f93-9188-685b6c64a2f5',
>> vds='Host[lago-basic-suite-master-host0,5eb7019e-28a3-4f93-9
>> 188-685b6c64a2f5]'}),
>> log id: 58f448b8
>> 2016-12-02 04:29:24,044-05 DEBUG
>> [org.ovirt.vdsm.jsonrpc.client.reactors.stomp.impl.Message] (default
>> task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] SEND
>> destination:jms.topic.vdsm_requests
>> reply-to:jms.topic.vdsm_responses
>> content-length:105
>>
>>
>> Please note that this runs on localhost with local bridge. So it is
>> not
>> likely to be network itself.
>>
>
> The main issue I see is that the VM run command has actually failed
> due to libvirt no accepting /dev/urandom as RNG 

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3910 - SUCCESS!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3910/,
Build Number: 3910,
Build Status: SUCCESS___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3909 - FAILURE!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3909/,
Build Number: 3909,
Build Status: FAILURE___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3908 - FAILURE!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3908/,
Build Number: 3908,
Build Status: FAILURE___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3907 - FAILURE!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3907/,
Build Number: 3907,
Build Status: FAILURE___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [ovirt-devel] Experimental Flow for Master Fails to Run a VM

[Arik Hadas]

Yaniv will try to lower the cluster level used in the system-tests to 4.0 -
this is supposed to solve the issue.
If it won't help (we will know it in about an hour), we'll add a db-script
that changes the rng device of the blank template only.

On Sun, Dec 4, 2016 at 3:34 PM, Eyal Edri  wrote:

> FYI,
>
> I opened a bug [1] to track this issue since I don't see any attempts to
> resolve the issue on the thread, hopefully a bug will get more attention.
> Opened on VDSM since we see the libvirt error there, feel free to move
> product/team.
>
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1401303
>
> On Sun, Dec 4, 2016 at 1:23 PM, Eyal Edri  wrote:
>
>> Not sure if relevant, but Juan posted a fix for SDK4 last time it
>> happened ( but different failure on log-collector ):
>>
>> https://gerrit.ovirt.org/#/c/67213/
>>
>> * Added `urandom` to the `RngSource` enumerated type.
>>
>> On Sun, Dec 4, 2016 at 9:17 AM, Eyal Edri  wrote:
>>
>>> And its still failing from Friday,
>>> Since we don't have official Centos 7.3 repos yet ( hopefully we'll have
>>> it this week, but as of this moment its not published yet ) , we have to
>>> either revert the offending patch
>>> or send a quick fix.
>>>
>>> Right now all experimental flows for master are not working and nightly
>>> rpms are not refreshed with new RPMs.
>>>
>>>
>>>
>>> On Fri, Dec 2, 2016 at 9:41 PM, Yaniv Kaul  wrote:
>>>


 On Dec 2, 2016 2:11 PM, "Anton Marchukov"  wrote:

 Hello Martin.

 Do by outdated you mean the old libvirt? If so that is that livirt
 available in CentOS 7.2? There is no 7.3 yet.


 Right, this is the issue.
 Y.


 Anton.

 On Fri, Dec 2, 2016 at 1:07 PM, Martin Polednik 
 wrote:

> On 02/12/16 10:55 +0100, Anton Marchukov wrote:
>
>> Hello All.
>>
>> Engine log can be viewed here:
>>
>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_ma
>> ster/3838/artifact/exported-artifacts/basic_suite_master.sh-
>> el7/exported-artifacts/test_logs/basic-suite-master/post-004
>> _basic_sanity.py/lago-basic-suite-master-engine/_var_log_ovi
>> rt-engine/engine.log
>>
>> I see the following exception there:
>>
>> 2016-12-02 04:29:24,030-05 DEBUG
>> [org.ovirt.vdsm.jsonrpc.client.internal.ResponseWorker]
>> (ResponseWorker) [83b6b5d] Message received: {"jsonrpc": "2.0", "id":
>> "ec254aad-441b-47e7-a644-aebddcc1d62c", "result": true}
>> 2016-12-02 04:29:24,030-05 ERROR
>> [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker)
>> [83b6b5d] Not able to update response for
>> "ec254aad-441b-47e7-a644-aebddcc1d62c"
>> 2016-12-02 04:29:24,041-05 DEBUG
>> [org.ovirt.engine.core.utils.timer.FixedDelayJobListener]
>> (DefaultQuartzScheduler3) [47a31d72] Rescheduling
>> DEFAULT.org.ovirt.engine.core.bll.gluster.GlusterSyncJob.ref
>> reshLightWeightData#-9223372036854775775
>> as there is no unfired trigger.
>> 2016-12-02 04:29:24,024-05 DEBUG
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default
>> task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] Exception:
>> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException:
>> VDSGenericException: VDSNetworkException: Timeout during xml-rpc call
>> at org.ovirt.engine.core.vdsbroke
>> r.vdsbroker.FutureVDSCommand.get(FutureVDSCommand.java:73)
>> [vdsbroker.jar:]
>>
>> ...
>>
>> 2016-12-02 04:29:24,042-05 ERROR
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default
>> task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] Timeout waiting for
>> VDSM response: Internal timeout occured
>> 2016-12-02 04:29:24,044-05 DEBUG
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand]
>> (default task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] START,
>> GetCapabilitiesVDSCommand(HostName = lago-basic-suite-master-host0,
>> VdsIdAndVdsVDSCommandParametersBase:{runAsync='true',
>> hostId='5eb7019e-28a3-4f93-9188-685b6c64a2f5',
>> vds='Host[lago-basic-suite-master-host0,5eb7019e-28a3-4f93-9
>> 188-685b6c64a2f5]'}),
>> log id: 58f448b8
>> 2016-12-02 04:29:24,044-05 DEBUG
>> [org.ovirt.vdsm.jsonrpc.client.reactors.stomp.impl.Message] (default
>> task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] SEND
>> destination:jms.topic.vdsm_requests
>> reply-to:jms.topic.vdsm_responses
>> content-length:105
>>
>>
>> Please note that this runs on localhost with local bridge. So it is
>> not
>> likely to be network itself.
>>
>
> The main issue I see is that the VM run command has actually failed
> due to libvirt no accepting /dev/urandom as RNG source[1]. This was
> done as engine patch and according to git log, 

Build failed in Jenkins: ovirt_master_system-tests #856

[jenkins]

See 

Changes:

[Yaniv Kaul] CHAP and IPv6 for iSCSI

[Gil Shinar] Using project param for new permutataion does not work

[Gil Shinar] Build of SDK V3 will be published for 4.1

[Gil Shinar] Updated nightly publishers with the new SDK jobs

--
[...truncated 850 lines...]
## Sun Dec  4 16:33:18 UTC 2016 Finished env: el7:epel-7-x86_64
##  took 1875 seconds
##  rc = 1
##
##! ERROR v
##! Last 20 log entries: 
logs/mocker-epel-7-x86_64.el7.basic_suite_master.sh/basic_suite_master.sh.log
##!
+ env_cleanup
+ echo '#'
#
+ local res=0
+ local uuid
+ echo ' Cleaning up'
 Cleaning up
+ [[ -e 

 ]]
+ echo '--- Cleaning with lago'
--- Cleaning with lago
+ lago --workdir 

 destroy --yes --all-prefixes
+ echo '--- Cleaning with lago done'
--- Cleaning with lago done
+ [[ 0 != \0 ]]
+ echo ' Cleanup done'
 Cleanup done
+ exit 0
+ exit
Took 1729 seconds
===
##!
##! ERROR ^^
##!
##
Build step 'Execute shell' marked build as failure
Performing Post build task...
Match found for :.* : True
Logical operation result is TRUE
Running script  : #!/bin/bash -xe
echo 'shell_scripts/system_tests.collect_logs.sh'

#
# Required jjb vars:
#version
#
VERSION=master
SUITE_TYPE=

WORKSPACE="$PWD"
OVIRT_SUITE="$SUITE_TYPE_suite_$VERSION"
TESTS_LOGS="$WORKSPACE/ovirt-system-tests/exported-artifacts"

rm -rf "$WORKSPACE/exported-artifacts"
mkdir -p "$WORKSPACE/exported-artifacts"

if [[ -d "$TESTS_LOGS" ]]; then
mv "$TESTS_LOGS/"* "$WORKSPACE/exported-artifacts/"
fi

[ovirt_master_system-tests] $ /bin/bash -xe /tmp/hudson2115841308271009663.sh
+ echo shell_scripts/system_tests.collect_logs.sh
shell_scripts/system_tests.collect_logs.sh
+ VERSION=master
+ SUITE_TYPE=
+ WORKSPACE=
+ OVIRT_SUITE=master
+ 
TESTS_LOGS=
+ rm -rf 

+ mkdir -p 

+ [[ -d 

 ]]
+ mv 

 

 

 

 

 

 

POST BUILD TASK : SUCCESS
END OF POST BUILD TASK : 0
Match found for :.* : True
Logical operation result is TRUE
Running script  : #!/bin/bash -xe
echo "shell-scripts/mock_cleanup.sh"

shopt -s nullglob


WORKSPACE="$PWD"

# Make clear this is the cleanup, helps reading the jenkins logs
cat 
+ cat
___
###
# #
#   CLEANUP   #
# #
###
+ logs=(./*log ./*/logs)
+ [[ -n ./ovirt-system-tests/logs ]]
+ for log in '"${logs[@]}"'
+ echo 'Copying ./ovirt-system-tests/logs to exported-artifacts'
Copying ./ovirt-system-tests/logs to exported-artifacts
+ mv ./ovirt-system-tests/logs exported-artifacts/
+ failed=false
+ mock_confs=("$WORKSPACE"/*/mocker*)
+ for mock_conf_file in '"${mock_confs[@]}"'
+ [[ -n 

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3906 - FAILURE!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3906/,
Build Number: 3906,
Build Status: FAILURE___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Jenkins build is back to normal : ovirt_master_publish-rpms_nightly #351

[jenkins]

See 

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3905 - FAILURE!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3905/,
Build Number: 3905,
Build Status: FAILURE___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Build failed in Jenkins: ovirt_master_publish-rpms_nightly #350

[jenkins]

See 

--
Started by user Gil Shinar
[EnvInject] - Loading node environment variables.
Building on master in workspace 

[WS-CLEANUP] Deleting project workspace...
[WS-CLEANUP] Done
[workspace] $ /bin/bash -xe /tmp/hudson2338604277032032992.sh
+ rm -rf 

+ mkdir 

Copied 6 artifacts from "ovirt-host-deploy_master_build-artifacts-el7-x86_64" 
build number 23
Copied 6 artifacts from "ovirt-host-deploy_master_build-artifacts-fc24-x86_64" 
build number 13
Copied 8 artifacts from "otopi_master_build-artifacts-el7-x86_64" build number 
31
Copied 8 artifacts from "otopi_master_build-artifacts-fc24-x86_64" build number 
19
Copied 5 artifacts from "ovirt-vmconsole_master_build-artifacts-el7-x86_64" 
build number 2
Copied 6 artifacts from "ovirt-vmconsole_master_build-artifacts-fc24-x86_64" 
build number 1
Copied 10 artifacts from "ovirt-imageio_master_build-artifacts-el7-x86_64" 
build number 61
Copied 10 artifacts from "ovirt-imageio_master_build-artifacts-fc24-x86_64" 
build number 24
Copied 4 artifacts from "ovirt-iso-uploader_master_build-artifacts-el7-x86_64" 
build number 9
Copied 4 artifacts from "ovirt-iso-uploader_master_build-artifacts-fc24-x86_64" 
build number 5
Copied 4 artifacts from "ovirt-log-collector_master_build-artifacts-el7-x86_64" 
build number 9
Copied 4 artifacts from 
"ovirt-log-collector_master_build-artifacts-fc24-x86_64" build number 5
Copied 4 artifacts from "ovirt-engine-cli_3.6_build-artifacts-el7-x86_64" build 
number 23
Copied 4 artifacts from "ovirt-engine-cli_3.6_build-artifacts-fc24-x86_64" 
build number 13
Copied 8 artifacts from 
"ovirt-engine-extension-aaa-ldap_master_create-rpms-el7-x86_64_merged" build 
number 21
Copied 8 artifacts from 
"ovirt-engine-extension-aaa-ldap_master_create-rpms-fc24-x86_64_merged" build 
number 5
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-misc_master_create-rpms-el7-x86_64_merged" build 
number 5
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-misc_master_create-rpms-fc24-x86_64_merged" build 
number 1
Copied 7 artifacts from 
"ovirt-engine-extension-logger-log4j_master_create-rpms-el7-x86_64_merged" 
build number 4
Copied 7 artifacts from 
"ovirt-engine-extension-logger-log4j_master_create-rpms-fc24-x86_64_merged" 
build number 3
Copied 4 artifacts from "ovirt-dwh_master_build-artifacts-el7-x86_64" build 
number 31
Copied 4 artifacts from "ovirt-dwh_master_build-artifacts-fc24-x86_64" build 
number 11
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-jdbc_master_create-rpms-el7-x86_64_merged" build 
number 15
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-jdbc_master_create-rpms-fc24-x86_64_merged" build 
number 10
Copied 4 artifacts from "ovirt-setup-lib_master_build-artifacts-el7-x86_64" 
build number 11
Copied 4 artifacts from "ovirt-setup-lib_master_build-artifacts-fc24-x86_64" 
build number 7
Copied 4 artifacts from "vdsm-jsonrpc-java_master_build-artifacts-el7-x86_64" 
build number 42
Copied 4 artifacts from "vdsm-jsonrpc-java_master_build-artifacts-fc24-x86_64" 
build number 20
Copied 3 artifacts from "ovirt-engine-sdk_master_build-artifacts-el7-x86_64" 
build number 101
Copied 5 artifacts from "ovirt-engine-sdk_master_build-artifacts-fc24-x86_64" 
build number 76
Copied 4 artifacts from 
"python-ovirt-engine-sdk4_master_build-artifacts-el7-x86_64" build number 2
Copied 5 artifacts from 
"python-ovirt-engine-sdk4_master_build-artifacts-fc24-x86_64" build number 2
Copied 4 artifacts from "ovirt-engine-sdk_master_build-artifacts-el7-ppc64le" 
build number 24
Copied 5 artifacts from "ovirt-engine-sdk_master_build-artifacts-fc24-ppc64le" 
build number 24
Copied 3 artifacts from 
"ovirt-engine-sdk-java_master_build-artifacts-el7-x86_64" build number 74
Copied 3 artifacts from 
"ovirt-engine-sdk-java_master_build-artifacts-fc24-x86_64" build number 54
Copied 4 artifacts from 
"java-ovirt-engine-sdk4_master_build-artifacts-el7-x86_64" build number 1
ERROR: Unable to find a build for artifact copy from: 
java-ovirt-engine-sdk4_master_build-artifacts-fc24-x86_64

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Build failed in Jenkins: ovirt_master_publish-rpms_nightly #349

[jenkins]

See 

--
Started by user Gil Shinar
[EnvInject] - Loading node environment variables.
Building on master in workspace 

[WS-CLEANUP] Deleting project workspace...
[WS-CLEANUP] Done
[workspace] $ /bin/bash -xe /tmp/hudson1637872988892786832.sh
+ rm -rf 

+ mkdir 

Copied 6 artifacts from "ovirt-host-deploy_master_build-artifacts-el7-x86_64" 
build number 23
Copied 6 artifacts from "ovirt-host-deploy_master_build-artifacts-fc24-x86_64" 
build number 13
Copied 8 artifacts from "otopi_master_build-artifacts-el7-x86_64" build number 
31
Copied 8 artifacts from "otopi_master_build-artifacts-fc24-x86_64" build number 
19
Copied 5 artifacts from "ovirt-vmconsole_master_build-artifacts-el7-x86_64" 
build number 2
Copied 6 artifacts from "ovirt-vmconsole_master_build-artifacts-fc24-x86_64" 
build number 1
Copied 10 artifacts from "ovirt-imageio_master_build-artifacts-el7-x86_64" 
build number 61
Copied 10 artifacts from "ovirt-imageio_master_build-artifacts-fc24-x86_64" 
build number 24
Copied 4 artifacts from "ovirt-iso-uploader_master_build-artifacts-el7-x86_64" 
build number 9
Copied 4 artifacts from "ovirt-iso-uploader_master_build-artifacts-fc24-x86_64" 
build number 5
Copied 4 artifacts from "ovirt-log-collector_master_build-artifacts-el7-x86_64" 
build number 9
Copied 4 artifacts from 
"ovirt-log-collector_master_build-artifacts-fc24-x86_64" build number 5
Copied 4 artifacts from "ovirt-engine-cli_3.6_build-artifacts-el7-x86_64" build 
number 23
Copied 4 artifacts from "ovirt-engine-cli_3.6_build-artifacts-fc24-x86_64" 
build number 13
Copied 8 artifacts from 
"ovirt-engine-extension-aaa-ldap_master_create-rpms-el7-x86_64_merged" build 
number 21
Copied 8 artifacts from 
"ovirt-engine-extension-aaa-ldap_master_create-rpms-fc24-x86_64_merged" build 
number 5
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-misc_master_create-rpms-el7-x86_64_merged" build 
number 5
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-misc_master_create-rpms-fc24-x86_64_merged" build 
number 1
Copied 7 artifacts from 
"ovirt-engine-extension-logger-log4j_master_create-rpms-el7-x86_64_merged" 
build number 4
Copied 7 artifacts from 
"ovirt-engine-extension-logger-log4j_master_create-rpms-fc24-x86_64_merged" 
build number 3
Copied 4 artifacts from "ovirt-dwh_master_build-artifacts-el7-x86_64" build 
number 31
Copied 4 artifacts from "ovirt-dwh_master_build-artifacts-fc24-x86_64" build 
number 11
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-jdbc_master_create-rpms-el7-x86_64_merged" build 
number 15
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-jdbc_master_create-rpms-fc24-x86_64_merged" build 
number 10
Copied 4 artifacts from "ovirt-setup-lib_master_build-artifacts-el7-x86_64" 
build number 11
Copied 4 artifacts from "ovirt-setup-lib_master_build-artifacts-fc24-x86_64" 
build number 7
Copied 4 artifacts from "vdsm-jsonrpc-java_master_build-artifacts-el7-x86_64" 
build number 42
Copied 4 artifacts from "vdsm-jsonrpc-java_master_build-artifacts-fc24-x86_64" 
build number 20
Copied 3 artifacts from "ovirt-engine-sdk_master_build-artifacts-el7-x86_64" 
build number 101
Copied 5 artifacts from "ovirt-engine-sdk_master_build-artifacts-fc24-x86_64" 
build number 76
Copied 4 artifacts from 
"python-ovirt-engine-sdk4_master_build-artifacts-el7-x86_64" build number 2
Copied 5 artifacts from 
"python-ovirt-engine-sdk4_master_build-artifacts-fc24-x86_64" build number 2
Copied 4 artifacts from "ovirt-engine-sdk_master_build-artifacts-el7-ppc64le" 
build number 24
Copied 5 artifacts from "ovirt-engine-sdk_master_build-artifacts-fc24-ppc64le" 
build number 24
Copied 3 artifacts from 
"ovirt-engine-sdk-java_master_build-artifacts-el7-x86_64" build number 74
Copied 3 artifacts from 
"ovirt-engine-sdk-java_master_build-artifacts-fc24-x86_64" build number 54
ERROR: Unable to find a build for artifact copy from: 
java-ovirt-engine-sdk4_master_build-artifacts-el7-x86_64

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Build failed in Jenkins: ovirt_master_publish-rpms_nightly #348

[jenkins]

See 

--
Started by user Gil Shinar
[EnvInject] - Loading node environment variables.
Building on master in workspace 

[WS-CLEANUP] Deleting project workspace...
[workspace] $ /bin/bash -xe /tmp/hudson3740535846473544521.sh
+ rm -rf 

+ mkdir 

Copied 6 artifacts from "ovirt-host-deploy_master_build-artifacts-el7-x86_64" 
build number 23
Copied 6 artifacts from "ovirt-host-deploy_master_build-artifacts-fc24-x86_64" 
build number 13
Copied 8 artifacts from "otopi_master_build-artifacts-el7-x86_64" build number 
31
Copied 8 artifacts from "otopi_master_build-artifacts-fc24-x86_64" build number 
19
Copied 5 artifacts from "ovirt-vmconsole_master_build-artifacts-el7-x86_64" 
build number 2
Copied 6 artifacts from "ovirt-vmconsole_master_build-artifacts-fc24-x86_64" 
build number 1
Copied 10 artifacts from "ovirt-imageio_master_build-artifacts-el7-x86_64" 
build number 61
Copied 10 artifacts from "ovirt-imageio_master_build-artifacts-fc24-x86_64" 
build number 24
Copied 4 artifacts from "ovirt-iso-uploader_master_build-artifacts-el7-x86_64" 
build number 9
Copied 4 artifacts from "ovirt-iso-uploader_master_build-artifacts-fc24-x86_64" 
build number 5
Copied 4 artifacts from "ovirt-log-collector_master_build-artifacts-el7-x86_64" 
build number 9
Copied 4 artifacts from 
"ovirt-log-collector_master_build-artifacts-fc24-x86_64" build number 5
Copied 4 artifacts from "ovirt-engine-cli_3.6_build-artifacts-el7-x86_64" build 
number 23
Copied 4 artifacts from "ovirt-engine-cli_3.6_build-artifacts-fc24-x86_64" 
build number 13
Copied 8 artifacts from 
"ovirt-engine-extension-aaa-ldap_master_create-rpms-el7-x86_64_merged" build 
number 21
Copied 8 artifacts from 
"ovirt-engine-extension-aaa-ldap_master_create-rpms-fc24-x86_64_merged" build 
number 5
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-misc_master_create-rpms-el7-x86_64_merged" build 
number 5
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-misc_master_create-rpms-fc24-x86_64_merged" build 
number 1
Copied 7 artifacts from 
"ovirt-engine-extension-logger-log4j_master_create-rpms-el7-x86_64_merged" 
build number 4
Copied 7 artifacts from 
"ovirt-engine-extension-logger-log4j_master_create-rpms-fc24-x86_64_merged" 
build number 3
Copied 4 artifacts from "ovirt-dwh_master_build-artifacts-el7-x86_64" build 
number 31
Copied 4 artifacts from "ovirt-dwh_master_build-artifacts-fc24-x86_64" build 
number 11
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-jdbc_master_create-rpms-el7-x86_64_merged" build 
number 15
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-jdbc_master_create-rpms-fc24-x86_64_merged" build 
number 10
Copied 4 artifacts from "ovirt-setup-lib_master_build-artifacts-el7-x86_64" 
build number 11
Copied 4 artifacts from "ovirt-setup-lib_master_build-artifacts-fc24-x86_64" 
build number 7
Copied 4 artifacts from "vdsm-jsonrpc-java_master_build-artifacts-el7-x86_64" 
build number 42
Copied 4 artifacts from "vdsm-jsonrpc-java_master_build-artifacts-fc24-x86_64" 
build number 20
Copied 3 artifacts from "ovirt-engine-sdk_master_build-artifacts-el7-x86_64" 
build number 101
Copied 5 artifacts from "ovirt-engine-sdk_master_build-artifacts-fc24-x86_64" 
build number 76
Copied 4 artifacts from 
"python-ovirt-engine-sdk4_master_build-artifacts-el7-x86_64" build number 2
ERROR: Unable to find a build for artifact copy from: 
python-ovirt-engine-sdk4_master_build-artifacts-fc24-x86_64

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Jenkins build is back to normal : ovirt_4.0_publish-rpms_nightly #249

[jenkins]

See 

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Build failed in Jenkins: ovirt_4.0_publish-rpms_nightly #248

[jenkins]

See 

--
Started by user Gil Shinar
[EnvInject] - Loading node environment variables.
Building on master in workspace 

[WS-CLEANUP] Deleting project workspace...
[WS-CLEANUP] Done
[workspace] $ /bin/bash -xe /tmp/hudson7208410681974797534.sh
+ rm -rf 

+ mkdir 

Copied 6 artifacts from "ovirt-host-deploy_4.0_build-artifacts-el7-x86_64" 
build number 17
Copied 6 artifacts from "ovirt-host-deploy_4.0_build-artifacts-fc23-x86_64" 
build number 17
Copied 8 artifacts from "otopi_4.0_build-artifacts-el7-x86_64" build number 14
Copied 8 artifacts from "otopi_4.0_build-artifacts-fc23-x86_64" build number 13
Copied 6 artifacts from "ovirt-vmconsole_4.0_build-artifacts-el7-x86_64" build 
number 1
Copied 6 artifacts from "ovirt-vmconsole_4.0_build-artifacts-fc23-x86_64" build 
number 1
Copied 10 artifacts from "ovirt-imageio_4.0_build-artifacts-el7-x86_64" build 
number 33
Copied 10 artifacts from "ovirt-imageio_4.0_build-artifacts-fc23-x86_64" build 
number 34
Copied 4 artifacts from "ovirt-iso-uploader_4.0_build-artifacts-el7-x86_64" 
build number 11
Copied 4 artifacts from "ovirt-iso-uploader_4.0_build-artifacts-fc23-x86_64" 
build number 11
Copied 4 artifacts from "ovirt-log-collector_4.0_build-artifacts-el7-x86_64" 
build number 7
Copied 4 artifacts from "ovirt-log-collector_4.0_build-artifacts-fc23-x86_64" 
build number 8
Copied 4 artifacts from "ovirt-engine-cli_3.6_build-artifacts-el7-x86_64" build 
number 23
Copied 4 artifacts from "ovirt-engine-cli_3.6_build-artifacts-fc23-x86_64" 
build number 23
Copied 8 artifacts from 
"ovirt-engine-extension-aaa-ldap_4.0_create-rpms-el7-x86_64_merged" build 
number 8
Copied 8 artifacts from 
"ovirt-engine-extension-aaa-ldap_4.0_create-rpms-fc23-x86_64_merged" build 
number 8
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-misc_4.0_create-rpms-el7-x86_64_merged" build 
number 1
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-misc_4.0_create-rpms-fc23-x86_64_merged" build 
number 1
Copied 7 artifacts from 
"ovirt-engine-extension-logger-log4j_4.0_create-rpms-el7-x86_64_merged" build 
number 3
Copied 7 artifacts from 
"ovirt-engine-extension-logger-log4j_4.0_create-rpms-fc23-x86_64_merged" build 
number 3
Copied 4 artifacts from "ovirt-dwh_4.0_build-artifacts-el7-x86_64" build number 
22
Copied 4 artifacts from "ovirt-dwh_4.0_build-artifacts-fc23-x86_64" build 
number 22
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-jdbc_4.0_create-rpms-el7-x86_64_merged" build 
number 10
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-jdbc_4.0_create-rpms-fc23-x86_64_merged" build 
number 10
Copied 3 artifacts from "ovirt-setup-lib_4.0_build-artifacts-el7-x86_64" build 
number 5
Copied 3 artifacts from "ovirt-setup-lib_4.0_build-artifacts-fc23-x86_64" build 
number 4
Copied 5 artifacts from "vdsm-jsonrpc-java_4.0_build-artifacts-el7-x86_64" 
build number 21
Copied 5 artifacts from "vdsm-jsonrpc-java_4.0_build-artifacts-fc23-x86_64" 
build number 21
Copied 24 artifacts from "ovirt-engine_4.0_build-artifacts-el7-x86_64" build 
number 1707
Copied 24 artifacts from "ovirt-engine_4.0_build-artifacts-fc23-x86_64" build 
number 1699
Copied 6 artifacts from "ovirt-engine-sdk_4.0_build-artifacts-el7-x86_64" build 
number 72
Copied 8 artifacts from "ovirt-engine-sdk_4.0_build-artifacts-fc23-x86_64" 
build number 75
Copied 3 artifacts from "ovirt-engine-sdk-java_4.0_build-artifacts-el7-x86_64" 
build number 66
Copied 3 artifacts from "ovirt-engine-sdk-java_4.0_build-artifacts-fc23-x86_64" 
build number 74
Copied 6 artifacts from 
"python-ovirt-engine-sdk4_4.0_build-artifacts-el7-x86_64" build number 2
Copied 8 artifacts from 
"python-ovirt-engine-sdk4_4.0_build-artifacts-fc23-x86_64" build number 2
Copied 6 artifacts from "java-ovirt-engine-sdk4_4.0_build-artifacts-el7-x86_64" 
build number 2
ERROR: Unable to find a build for artifact copy from: 
java-ovirt-engine-sdk4_4.0_build-artifacts-fc23-x86_64

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Build failed in Jenkins: ovirt_4.0_publish-rpms_nightly #247

[jenkins]

See 

--
Started by user Gil Shinar
[EnvInject] - Loading node environment variables.
Building on master in workspace 

[WS-CLEANUP] Deleting project workspace...
[workspace] $ /bin/bash -xe /tmp/hudson7362465232987529782.sh
+ rm -rf 

+ mkdir 

Copied 6 artifacts from "ovirt-host-deploy_4.0_build-artifacts-el7-x86_64" 
build number 17
Copied 6 artifacts from "ovirt-host-deploy_4.0_build-artifacts-fc23-x86_64" 
build number 17
Copied 8 artifacts from "otopi_4.0_build-artifacts-el7-x86_64" build number 14
Copied 8 artifacts from "otopi_4.0_build-artifacts-fc23-x86_64" build number 13
Copied 6 artifacts from "ovirt-vmconsole_4.0_build-artifacts-el7-x86_64" build 
number 1
Copied 6 artifacts from "ovirt-vmconsole_4.0_build-artifacts-fc23-x86_64" build 
number 1
Copied 10 artifacts from "ovirt-imageio_4.0_build-artifacts-el7-x86_64" build 
number 33
Copied 10 artifacts from "ovirt-imageio_4.0_build-artifacts-fc23-x86_64" build 
number 34
Copied 4 artifacts from "ovirt-iso-uploader_4.0_build-artifacts-el7-x86_64" 
build number 11
Copied 4 artifacts from "ovirt-iso-uploader_4.0_build-artifacts-fc23-x86_64" 
build number 11
Copied 4 artifacts from "ovirt-log-collector_4.0_build-artifacts-el7-x86_64" 
build number 7
Copied 4 artifacts from "ovirt-log-collector_4.0_build-artifacts-fc23-x86_64" 
build number 8
Copied 4 artifacts from "ovirt-engine-cli_3.6_build-artifacts-el7-x86_64" build 
number 23
Copied 4 artifacts from "ovirt-engine-cli_3.6_build-artifacts-fc23-x86_64" 
build number 23
Copied 8 artifacts from 
"ovirt-engine-extension-aaa-ldap_4.0_create-rpms-el7-x86_64_merged" build 
number 8
Copied 8 artifacts from 
"ovirt-engine-extension-aaa-ldap_4.0_create-rpms-fc23-x86_64_merged" build 
number 8
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-misc_4.0_create-rpms-el7-x86_64_merged" build 
number 1
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-misc_4.0_create-rpms-fc23-x86_64_merged" build 
number 1
Copied 7 artifacts from 
"ovirt-engine-extension-logger-log4j_4.0_create-rpms-el7-x86_64_merged" build 
number 3
Copied 7 artifacts from 
"ovirt-engine-extension-logger-log4j_4.0_create-rpms-fc23-x86_64_merged" build 
number 3
Copied 4 artifacts from "ovirt-dwh_4.0_build-artifacts-el7-x86_64" build number 
22
Copied 4 artifacts from "ovirt-dwh_4.0_build-artifacts-fc23-x86_64" build 
number 22
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-jdbc_4.0_create-rpms-el7-x86_64_merged" build 
number 10
Copied 7 artifacts from 
"ovirt-engine-extension-aaa-jdbc_4.0_create-rpms-fc23-x86_64_merged" build 
number 10
Copied 3 artifacts from "ovirt-setup-lib_4.0_build-artifacts-el7-x86_64" build 
number 5
Copied 3 artifacts from "ovirt-setup-lib_4.0_build-artifacts-fc23-x86_64" build 
number 4
Copied 5 artifacts from "vdsm-jsonrpc-java_4.0_build-artifacts-el7-x86_64" 
build number 21
Copied 5 artifacts from "vdsm-jsonrpc-java_4.0_build-artifacts-fc23-x86_64" 
build number 21
Copied 24 artifacts from "ovirt-engine_4.0_build-artifacts-el7-x86_64" build 
number 1707
Copied 24 artifacts from "ovirt-engine_4.0_build-artifacts-fc23-x86_64" build 
number 1699
Copied 6 artifacts from "ovirt-engine-sdk_4.0_build-artifacts-el7-x86_64" build 
number 72
Copied 8 artifacts from "ovirt-engine-sdk_4.0_build-artifacts-fc23-x86_64" 
build number 75
Copied 3 artifacts from "ovirt-engine-sdk-java_4.0_build-artifacts-el7-x86_64" 
build number 66
Copied 3 artifacts from "ovirt-engine-sdk-java_4.0_build-artifacts-fc23-x86_64" 
build number 74
Copied 6 artifacts from 
"python-ovirt-engine-sdk4_4.0_build-artifacts-el7-x86_64" build number 2
ERROR: Unable to find a build for artifact copy from: 
python-ovirt-engine-sdk4_4.0_build-artifacts-fc23-x86_64

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3904 - FAILURE!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3904/,
Build Number: 3904,
Build Status: FAILURE___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3903 - FAILURE!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3903/,
Build Number: 3903,
Build Status: FAILURE___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-900) Re: Rebase over other author's patch cannot be pushed to gerrit

[eyal edri [Administrator] (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23827#comment-23827
 ] 

eyal edri [Administrator] commented on OVIRT-900:
-

[~sbend...@redhat.com] can you check if rebasing on someone else patch and 
pushing again requires the 'forget identity' permission or its a different one?

> Re: Rebase over other author's patch cannot be pushed to gerrit
> ---
>
> Key: OVIRT-900
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-900
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: Barak Korren
>Assignee: Shlomo Ben David
>
> Forwarding to infra-support.
> On 1 December 2016 at 18:03, Yaniv Bronheim  wrote:
> > Not sure since when it was changed, but I noticed that I can't push patches
> > if I'm not the author
> >
> > Counting objects: 50, done.
> > Delta compression using up to 4 threads.
> > Compressing objects: 100% (50/50), done.
> > Writing objects: 100% (50/50), 36.66 KiB | 0 bytes/s, done.
> > Total 50 (delta 34), reused 0 (delta 0)
> > remote: Resolving deltas: 100% (34/34)
> > remote: Processing changes: refs: 1, done
> > remote:
> > remote: ERROR:  In commit db14ec7c1555a9eb37a0fb931bbb4ebdfc674bb4
> > remote: ERROR:  author email address rnach...@redhat.com
> > remote: ERROR:  does not match your user account.
> > remote: ERROR:
> > remote: ERROR:  The following addresses are currently registered:
> > remote: ERROR:bronh...@gmail.com
> > remote: ERROR:ybron...@redhat.com
> > remote: ERROR:
> > remote: ERROR:  To register an email address, please visit:
> > remote: ERROR:  https://gerrit.ovirt.org/#/settings/contact
> > remote:
> > remote:
> > To ssh://ybron...@gerrit.ovirt.org:29418/vdsm
> >  ! [remote rejected] HEAD -> refs/for/master (invalid author)
> > error: failed to push some refs to
> > 'ssh://ybron...@gerrit.ovirt.org:29418/vdsm'
> >
> > We must have permissions to do that, this is part of the rebasing part, and
> > I think its fine to fix patches on behalf of someone else.. but its not the
> > best practice for reviewing.
> > anyway, please undo this change, unless its something that related only to
> > my env.. let me know
> >
> > Thanks
> >
> > --
> > Yaniv Bronhaim.
> >
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> -- 
> Barak Korren
> bkor...@redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3902 - FAILURE!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3902/,
Build Number: 3902,
Build Status: FAILURE___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-900) Re: Rebase over other author's patch cannot be pushed to gerrit

[ybronhei (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23826#comment-23826
 ] 

ybronhei commented on OVIRT-900:


you can always ignore the patchset and push your version again. otherwise
you cant rebase your patch on it I think

On Sun, Dec 4, 2016 at 3:00 PM, eyal edri [Administrator] (oVirt JIRA) <




-- 
*Yaniv Bronhaim.*


> Re: Rebase over other author's patch cannot be pushed to gerrit
> ---
>
> Key: OVIRT-900
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-900
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: Barak Korren
>Assignee: Shlomo Ben David
>
> Forwarding to infra-support.
> On 1 December 2016 at 18:03, Yaniv Bronheim  wrote:
> > Not sure since when it was changed, but I noticed that I can't push patches
> > if I'm not the author
> >
> > Counting objects: 50, done.
> > Delta compression using up to 4 threads.
> > Compressing objects: 100% (50/50), done.
> > Writing objects: 100% (50/50), 36.66 KiB | 0 bytes/s, done.
> > Total 50 (delta 34), reused 0 (delta 0)
> > remote: Resolving deltas: 100% (34/34)
> > remote: Processing changes: refs: 1, done
> > remote:
> > remote: ERROR:  In commit db14ec7c1555a9eb37a0fb931bbb4ebdfc674bb4
> > remote: ERROR:  author email address rnach...@redhat.com
> > remote: ERROR:  does not match your user account.
> > remote: ERROR:
> > remote: ERROR:  The following addresses are currently registered:
> > remote: ERROR:bronh...@gmail.com
> > remote: ERROR:ybron...@redhat.com
> > remote: ERROR:
> > remote: ERROR:  To register an email address, please visit:
> > remote: ERROR:  https://gerrit.ovirt.org/#/settings/contact
> > remote:
> > remote:
> > To ssh://ybron...@gerrit.ovirt.org:29418/vdsm
> >  ! [remote rejected] HEAD -> refs/for/master (invalid author)
> > error: failed to push some refs to
> > 'ssh://ybron...@gerrit.ovirt.org:29418/vdsm'
> >
> > We must have permissions to do that, this is part of the rebasing part, and
> > I think its fine to fix patches on behalf of someone else.. but its not the
> > best practice for reviewing.
> > anyway, please undo this change, unless its something that related only to
> > my env.. let me know
> >
> > Thanks
> >
> > --
> > Yaniv Bronhaim.
> >
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> -- 
> Barak Korren
> bkor...@redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [JIRA] (OVIRT-900) Re: Rebase over other author's patch cannot be pushed to gerrit

[Yaniv Bronheim]

you can always ignore the patchset and push your version again. otherwise
you cant rebase your patch on it I think

On Sun, Dec 4, 2016 at 3:00 PM, eyal edri [Administrator] (oVirt JIRA) <
j...@ovirt-jira.atlassian.net> wrote:

>
> [ https://ovirt-jira.atlassian.net/browse/OVIRT-900?page=com.
> atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=23824#comment-23824 ]
>
> eyal edri [Administrator] commented on OVIRT-900:
> -
>
> So what you're saying is any 'registered user' should have 'forge author
> identity' permission?
> Isn't that a bit of a security issue?
>
> On Sun, Dec 4, 2016 at 2:58 PM, ybronhei (oVirt JIRA) <
>
>
>
>
> --
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
>
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>
>
> > Re: Rebase over other author's patch cannot be pushed to gerrit
> > ---
> >
> > Key: OVIRT-900
> > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-900
> > Project: oVirt - virtualization made easy
> >  Issue Type: By-EMAIL
> >Reporter: Barak Korren
> >Assignee: Shlomo Ben David
> >
> > Forwarding to infra-support.
> > On 1 December 2016 at 18:03, Yaniv Bronheim  wrote:
> > > Not sure since when it was changed, but I noticed that I can't push
> patches
> > > if I'm not the author
> > >
> > > Counting objects: 50, done.
> > > Delta compression using up to 4 threads.
> > > Compressing objects: 100% (50/50), done.
> > > Writing objects: 100% (50/50), 36.66 KiB | 0 bytes/s, done.
> > > Total 50 (delta 34), reused 0 (delta 0)
> > > remote: Resolving deltas: 100% (34/34)
> > > remote: Processing changes: refs: 1, done
> > > remote:
> > > remote: ERROR:  In commit db14ec7c1555a9eb37a0fb931bbb4ebdfc674bb4
> > > remote: ERROR:  author email address rnach...@redhat.com
> > > remote: ERROR:  does not match your user account.
> > > remote: ERROR:
> > > remote: ERROR:  The following addresses are currently registered:
> > > remote: ERROR:bronh...@gmail.com
> > > remote: ERROR:ybron...@redhat.com
> > > remote: ERROR:
> > > remote: ERROR:  To register an email address, please visit:
> > > remote: ERROR:  https://gerrit.ovirt.org/#/settings/contact
> > > remote:
> > > remote:
> > > To ssh://ybron...@gerrit.ovirt.org:29418/vdsm
> > >  ! [remote rejected] HEAD -> refs/for/master (invalid author)
> > > error: failed to push some refs to
> > > 'ssh://ybron...@gerrit.ovirt.org:29418/vdsm'
> > >
> > > We must have permissions to do that, this is part of the rebasing
> part, and
> > > I think its fine to fix patches on behalf of someone else.. but its
> not the
> > > best practice for reviewing.
> > > anyway, please undo this change, unless its something that related
> only to
> > > my env.. let me know
> > >
> > > Thanks
> > >
> > > --
> > > Yaniv Bronhaim.
> > >
> > > ___
> > > Infra mailing list
> > > Infra@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/infra
> > >
> > --
> > Barak Korren
> > bkor...@redhat.com
> > RHCE, RHCi, RHV-DevOps Team
> > https://ifireball.wordpress.com/
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v1000.610.2#100023)
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>



-- 
*Yaniv Bronhaim.*
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [ovirt-devel] Experimental Flow for Master Fails to Run a VM

[Eyal Edri]

FYI,

I opened a bug [1] to track this issue since I don't see any attempts to
resolve the issue on the thread, hopefully a bug will get more attention.
Opened on VDSM since we see the libvirt error there, feel free to move
product/team.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1401303

On Sun, Dec 4, 2016 at 1:23 PM, Eyal Edri  wrote:

> Not sure if relevant, but Juan posted a fix for SDK4 last time it happened
> ( but different failure on log-collector ):
>
> https://gerrit.ovirt.org/#/c/67213/
>
> * Added `urandom` to the `RngSource` enumerated type.
>
> On Sun, Dec 4, 2016 at 9:17 AM, Eyal Edri  wrote:
>
>> And its still failing from Friday,
>> Since we don't have official Centos 7.3 repos yet ( hopefully we'll have
>> it this week, but as of this moment its not published yet ) , we have to
>> either revert the offending patch
>> or send a quick fix.
>>
>> Right now all experimental flows for master are not working and nightly
>> rpms are not refreshed with new RPMs.
>>
>>
>>
>> On Fri, Dec 2, 2016 at 9:41 PM, Yaniv Kaul  wrote:
>>
>>>
>>>
>>> On Dec 2, 2016 2:11 PM, "Anton Marchukov"  wrote:
>>>
>>> Hello Martin.
>>>
>>> Do by outdated you mean the old libvirt? If so that is that livirt
>>> available in CentOS 7.2? There is no 7.3 yet.
>>>
>>>
>>> Right, this is the issue.
>>> Y.
>>>
>>>
>>> Anton.
>>>
>>> On Fri, Dec 2, 2016 at 1:07 PM, Martin Polednik 
>>> wrote:
>>>
 On 02/12/16 10:55 +0100, Anton Marchukov wrote:

> Hello All.
>
> Engine log can be viewed here:
>
> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_ma
> ster/3838/artifact/exported-artifacts/basic_suite_master.sh-
> el7/exported-artifacts/test_logs/basic-suite-master/post-004
> _basic_sanity.py/lago-basic-suite-master-engine/_var_log_ovi
> rt-engine/engine.log
>
> I see the following exception there:
>
> 2016-12-02 04:29:24,030-05 DEBUG
> [org.ovirt.vdsm.jsonrpc.client.internal.ResponseWorker]
> (ResponseWorker) [83b6b5d] Message received: {"jsonrpc": "2.0", "id":
> "ec254aad-441b-47e7-a644-aebddcc1d62c", "result": true}
> 2016-12-02 04:29:24,030-05 ERROR
> [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker)
> [83b6b5d] Not able to update response for
> "ec254aad-441b-47e7-a644-aebddcc1d62c"
> 2016-12-02 04:29:24,041-05 DEBUG
> [org.ovirt.engine.core.utils.timer.FixedDelayJobListener]
> (DefaultQuartzScheduler3) [47a31d72] Rescheduling
> DEFAULT.org.ovirt.engine.core.bll.gluster.GlusterSyncJob.ref
> reshLightWeightData#-9223372036854775775
> as there is no unfired trigger.
> 2016-12-02 04:29:24,024-05 DEBUG
> [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default
> task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] Exception:
> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException:
> VDSGenericException: VDSNetworkException: Timeout during xml-rpc call
> at org.ovirt.engine.core.vdsbroke
> r.vdsbroker.FutureVDSCommand.get(FutureVDSCommand.java:73)
> [vdsbroker.jar:]
>
> ...
>
> 2016-12-02 04:29:24,042-05 ERROR
> [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default
> task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] Timeout waiting for
> VDSM response: Internal timeout occured
> 2016-12-02 04:29:24,044-05 DEBUG
> [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand]
> (default task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] START,
> GetCapabilitiesVDSCommand(HostName = lago-basic-suite-master-host0,
> VdsIdAndVdsVDSCommandParametersBase:{runAsync='true',
> hostId='5eb7019e-28a3-4f93-9188-685b6c64a2f5',
> vds='Host[lago-basic-suite-master-host0,5eb7019e-28a3-4f93-9
> 188-685b6c64a2f5]'}),
> log id: 58f448b8
> 2016-12-02 04:29:24,044-05 DEBUG
> [org.ovirt.vdsm.jsonrpc.client.reactors.stomp.impl.Message] (default
> task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] SEND
> destination:jms.topic.vdsm_requests
> reply-to:jms.topic.vdsm_responses
> content-length:105
>
>
> Please note that this runs on localhost with local bridge. So it is not
> likely to be network itself.
>

 The main issue I see is that the VM run command has actually failed
 due to libvirt no accepting /dev/urandom as RNG source[1]. This was
 done as engine patch and according to git log, posted around Mon Nov
 28. Also adding Jakub - this should either not happen from engine's
 point of view or the lago host is outdated.

 [1]
 http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_ma
 ster/3838/artifact/exported-artifacts/basic_suite_master.sh-
 el7/exported-artifacts/test_logs/basic-suite-master/post-004
 _basic_sanity.py/lago-basic-suite-master-host0/_var_log_vdsm/vdsm.log


 Anton.

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3901 - FAILURE!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3901/,
Build Number: 3901,
Build Status: FAILURE___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-900) Re: Rebase over other author's patch cannot be pushed to gerrit

[eyal edri [Administrator] (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23824#comment-23824
 ] 

eyal edri [Administrator] commented on OVIRT-900:
-

So what you're saying is any 'registered user' should have 'forge author
identity' permission?
Isn't that a bit of a security issue?

On Sun, Dec 4, 2016 at 2:58 PM, ybronhei (oVirt JIRA) <




-- 
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)


> Re: Rebase over other author's patch cannot be pushed to gerrit
> ---
>
> Key: OVIRT-900
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-900
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: Barak Korren
>Assignee: Shlomo Ben David
>
> Forwarding to infra-support.
> On 1 December 2016 at 18:03, Yaniv Bronheim  wrote:
> > Not sure since when it was changed, but I noticed that I can't push patches
> > if I'm not the author
> >
> > Counting objects: 50, done.
> > Delta compression using up to 4 threads.
> > Compressing objects: 100% (50/50), done.
> > Writing objects: 100% (50/50), 36.66 KiB | 0 bytes/s, done.
> > Total 50 (delta 34), reused 0 (delta 0)
> > remote: Resolving deltas: 100% (34/34)
> > remote: Processing changes: refs: 1, done
> > remote:
> > remote: ERROR:  In commit db14ec7c1555a9eb37a0fb931bbb4ebdfc674bb4
> > remote: ERROR:  author email address rnach...@redhat.com
> > remote: ERROR:  does not match your user account.
> > remote: ERROR:
> > remote: ERROR:  The following addresses are currently registered:
> > remote: ERROR:bronh...@gmail.com
> > remote: ERROR:ybron...@redhat.com
> > remote: ERROR:
> > remote: ERROR:  To register an email address, please visit:
> > remote: ERROR:  https://gerrit.ovirt.org/#/settings/contact
> > remote:
> > remote:
> > To ssh://ybron...@gerrit.ovirt.org:29418/vdsm
> >  ! [remote rejected] HEAD -> refs/for/master (invalid author)
> > error: failed to push some refs to
> > 'ssh://ybron...@gerrit.ovirt.org:29418/vdsm'
> >
> > We must have permissions to do that, this is part of the rebasing part, and
> > I think its fine to fix patches on behalf of someone else.. but its not the
> > best practice for reviewing.
> > anyway, please undo this change, unless its something that related only to
> > my env.. let me know
> >
> > Thanks
> >
> > --
> > Yaniv Bronhaim.
> >
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> -- 
> Barak Korren
> bkor...@redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-900) Re: Rebase over other author's patch cannot be pushed to gerrit

[ybronhei (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23823#comment-23823
 ] 

ybronhei commented on OVIRT-900:


no.. this is not the issue here. I don't try to merge, I try to push a
change on a patch that im not the author of it. everyone should allow to do
so

On Sun, Dec 4, 2016 at 1:25 PM, eyal edri [Administrator] (oVirt JIRA) <




-- 
*Yaniv Bronhaim.*


> Re: Rebase over other author's patch cannot be pushed to gerrit
> ---
>
> Key: OVIRT-900
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-900
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: Barak Korren
>Assignee: Shlomo Ben David
>
> Forwarding to infra-support.
> On 1 December 2016 at 18:03, Yaniv Bronheim  wrote:
> > Not sure since when it was changed, but I noticed that I can't push patches
> > if I'm not the author
> >
> > Counting objects: 50, done.
> > Delta compression using up to 4 threads.
> > Compressing objects: 100% (50/50), done.
> > Writing objects: 100% (50/50), 36.66 KiB | 0 bytes/s, done.
> > Total 50 (delta 34), reused 0 (delta 0)
> > remote: Resolving deltas: 100% (34/34)
> > remote: Processing changes: refs: 1, done
> > remote:
> > remote: ERROR:  In commit db14ec7c1555a9eb37a0fb931bbb4ebdfc674bb4
> > remote: ERROR:  author email address rnach...@redhat.com
> > remote: ERROR:  does not match your user account.
> > remote: ERROR:
> > remote: ERROR:  The following addresses are currently registered:
> > remote: ERROR:bronh...@gmail.com
> > remote: ERROR:ybron...@redhat.com
> > remote: ERROR:
> > remote: ERROR:  To register an email address, please visit:
> > remote: ERROR:  https://gerrit.ovirt.org/#/settings/contact
> > remote:
> > remote:
> > To ssh://ybron...@gerrit.ovirt.org:29418/vdsm
> >  ! [remote rejected] HEAD -> refs/for/master (invalid author)
> > error: failed to push some refs to
> > 'ssh://ybron...@gerrit.ovirt.org:29418/vdsm'
> >
> > We must have permissions to do that, this is part of the rebasing part, and
> > I think its fine to fix patches on behalf of someone else.. but its not the
> > best practice for reviewing.
> > anyway, please undo this change, unless its something that related only to
> > my env.. let me know
> >
> > Thanks
> >
> > --
> > Yaniv Bronhaim.
> >
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> -- 
> Barak Korren
> bkor...@redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [JIRA] (OVIRT-900) Re: Rebase over other author's patch cannot be pushed to gerrit

[Yaniv Bronheim]

no.. this is not the issue here. I don't try to merge, I try to push a
change on a patch that im not the author of it. everyone should allow to do
so

On Sun, Dec 4, 2016 at 1:25 PM, eyal edri [Administrator] (oVirt JIRA) <
j...@ovirt-jira.atlassian.net> wrote:

>
> [ https://ovirt-jira.atlassian.net/browse/OVIRT-900?page=com.
> atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=23821#comment-23821 ]
>
> eyal edri [Administrator] commented on OVIRT-900:
> -
>
> OK, so as I suggested its best to verify the list of people in those
> groups and add/remove people who are missing.
>
> > Re: Rebase over other author's patch cannot be pushed to gerrit
> > ---
> >
> > Key: OVIRT-900
> > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-900
> > Project: oVirt - virtualization made easy
> >  Issue Type: By-EMAIL
> >Reporter: Barak Korren
> >Assignee: Shlomo Ben David
> >
> > Forwarding to infra-support.
> > On 1 December 2016 at 18:03, Yaniv Bronheim  wrote:
> > > Not sure since when it was changed, but I noticed that I can't push
> patches
> > > if I'm not the author
> > >
> > > Counting objects: 50, done.
> > > Delta compression using up to 4 threads.
> > > Compressing objects: 100% (50/50), done.
> > > Writing objects: 100% (50/50), 36.66 KiB | 0 bytes/s, done.
> > > Total 50 (delta 34), reused 0 (delta 0)
> > > remote: Resolving deltas: 100% (34/34)
> > > remote: Processing changes: refs: 1, done
> > > remote:
> > > remote: ERROR:  In commit db14ec7c1555a9eb37a0fb931bbb4ebdfc674bb4
> > > remote: ERROR:  author email address rnach...@redhat.com
> > > remote: ERROR:  does not match your user account.
> > > remote: ERROR:
> > > remote: ERROR:  The following addresses are currently registered:
> > > remote: ERROR:bronh...@gmail.com
> > > remote: ERROR:ybron...@redhat.com
> > > remote: ERROR:
> > > remote: ERROR:  To register an email address, please visit:
> > > remote: ERROR:  https://gerrit.ovirt.org/#/settings/contact
> > > remote:
> > > remote:
> > > To ssh://ybron...@gerrit.ovirt.org:29418/vdsm
> > >  ! [remote rejected] HEAD -> refs/for/master (invalid author)
> > > error: failed to push some refs to
> > > 'ssh://ybron...@gerrit.ovirt.org:29418/vdsm'
> > >
> > > We must have permissions to do that, this is part of the rebasing
> part, and
> > > I think its fine to fix patches on behalf of someone else.. but its
> not the
> > > best practice for reviewing.
> > > anyway, please undo this change, unless its something that related
> only to
> > > my env.. let me know
> > >
> > > Thanks
> > >
> > > --
> > > Yaniv Bronhaim.
> > >
> > > ___
> > > Infra mailing list
> > > Infra@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/infra
> > >
> > --
> > Barak Korren
> > bkor...@redhat.com
> > RHCE, RHCi, RHV-DevOps Team
> > https://ifireball.wordpress.com/
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v1000.610.2#100023)
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>



-- 
*Yaniv Bronhaim.*
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3900 - FAILURE!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3900/,
Build Number: 3900,
Build Status: FAILURE___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3899 - FAILURE!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3899/,
Build Number: 3899,
Build Status: FAILURE___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-902) Speed up mock_runner.sh setup time by using caches.

[Barak Korren (oVirt JIRA)]

 [ 
https://ovirt-jira.atlassian.net/browse/OVIRT-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Barak Korren reassigned OVIRT-902:
--

Assignee: Barak Korren  (was: infra)

> Speed up mock_runner.sh setup time by using caches.
> ---
>
> Key: OVIRT-902
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-902
> Project: oVirt - virtualization made easy
>  Issue Type: Improvement
>Reporter: Barak Korren
>Assignee: Barak Korren
>Priority: High
>  Labels: mock, mock_runner.sh, standard-ci
>
> We've already known that setting up mock takes a while, but mock has some 
> built-in caching features that should allow us to speed this up.
> We need to ensure those features are enabled by mock_runner.sh. The mock 
> options to look at are:
> * root_cache_enable
> * yum_cache_enable
> Both these options should be set to true in the mock chroot config file.
> We've been using these option downstream in minimead and the vdsm build 
> scripts, so they should be safe to use.



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Vdsm tests are 4X times faster on travis

[Barak Korren]

> To debug this we need to get a shell on a jenkins slave with the exact
> environment of
> a running job.

Perhaps try to check if this reproduces with mock_runner.sh.

You can try running with with something like:

JENKINS=
cd 
$JENKINS/mock_configs/mock_runner.sh --patch-only \
  --mock-confs-dir $JENKINS/mock_configs "fc24.*x86_64"



-- 
Barak Korren
bkor...@redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Vdsm tests are 4X times faster on travis

[Nir Soffer]

On Sun, Dec 4, 2016 at 9:59 AM, Barak Korren  wrote:
> On 3 December 2016 at 21:36, Nir Soffer  wrote:
>> HI all,
>>
>> Watching vdsm travis builds in the last weeks, it is clear that vdsm tests
>> on travis are about 4X times faster compared with jenkins builds.
>>
>> Here is a typical build:
>>
>> ovirt ci: 
>> http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/5101/consoleFull
>> travis ci: https://travis-ci.org/nirs/vdsm/builds/179056079
>>
>> The build took 4:34 on travis, and 19:34 on ovirt ci.
>
> Interesting, thanks for looking at this!
>
>>
>> This has a huge impact on vdsm maintainers. Having to wait 20 minutes
>> for each patch
>> means that we must ignore the ci and merge and hope that previous tests 
>> without
>> rebasing on master were good enough.
>>
>> The builds are mostly the same, expect:
>>
>> - In travis we don't check if the build system was changed and
>> packages should be built
>>   takes 9:18 minutes in ovirt ci.
>
> Well, I guess the infra team can't help with that, but still, is there
> anything we could do at the infrastructure level to speed this up?

The line taking 9 minutes is:

if git diff-tree --no-commit-id --name-only -r HEAD | egrep
--quiet 'vdsm.spec.in|Makefile.am' ; then
./automation/build-artifacts.sh
yum -y install "$EXPORT_DIR/"!(*.src).rpm
fi

In the build above the condition is false, and we not run
build-artifacts.sh or installing the packages.
The time is spent in:

git diff-tree --no-commit-id --name-only -r HEAD | egrep --quiet
'vdsm.spec.in|Makefile.am'

Running locally:

$ time git diff-tree --no-commit-id --name-only -r HEAD | egrep
--quiet 'vdsm.spec.in|Makefile.am'

real 0m0.009s
user 0m0.006s
sys 0m0.009s

To debug this we need to get a shell on a jenkins slave with the exact
environment of
a running job.

>
>> - In travis we don't clean or install anything before the test, we use
>> a container with all the
>>   available packages, pulled from dockerhub.
>>   takes about 3:52 minutes in ovirt ci
>
> Well, I guess this is where we (the infra team) should pay attention.
> We do have a plan to switch from mock to Docker at some point
> (OVIRT-873 [1]), but it'll take a while until we can make such a large
> switch.
>
> It the meantime there may be some low-hanging fruit we can pick to
> make things faster. Looking at the same log:
>
> 16:03:28 Init took 77 seconds
>
> 16:05:50 Install packages took 142 seconds
>
> We may be able to speed those up - looking at the way muck is
> configured, we may be running with its caches turned off (I'm not yet
> 100% sure about this - muck_runner.sh is not the simplest script...).
> I've created OVIRT-902 [2] for us to look at this.
>
>> - In travis we don't enable coverage. Running the tests with coverage
>> may slow down the tests
>>   takes 5:04 minutes in ovirt ci
>>   creating the coverage report takes only 15 seconds, not interesting
>
> We can easily check this by just sending a patch with coverage turned
> on and then sending another patch set for the same patch with coverage
> turned off.
>
>> - In travis we don't cleanup anything after the test
>>   this takes 34 seconds in ovirt ci
>
> We can look at speeding this up - or perhaps just change things so
> that results are reported as soon as check_patch.sh is done as opposed
> to when the Jenkins job is done.
> There may be some pitfalls here so I need to think a little more
> before I recommend going down this path.
>
>> The biggest problem is the build system check taking 9:18 minutes.
>> fixing it will cut the build time in half.
>
> Please try fixing that, or maybe this should just move to build_artifacts.sh?
>
> [1]: https://ovirt-jira.atlassian.net/browse/OVIRT-873
> [2]: https://ovirt-jira.atlassian.net/browse/OVIRT-902
>
> --
> Barak Korren
> bkor...@redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [ovirt-devel] Experimental Flow for Master Fails to Run a VM

[Eyal Edri]

Not sure if relevant, but Juan posted a fix for SDK4 last time it happened
( but different failure on log-collector ):

https://gerrit.ovirt.org/#/c/67213/

* Added `urandom` to the `RngSource` enumerated type.

On Sun, Dec 4, 2016 at 9:17 AM, Eyal Edri  wrote:

> And its still failing from Friday,
> Since we don't have official Centos 7.3 repos yet ( hopefully we'll have
> it this week, but as of this moment its not published yet ) , we have to
> either revert the offending patch
> or send a quick fix.
>
> Right now all experimental flows for master are not working and nightly
> rpms are not refreshed with new RPMs.
>
>
>
> On Fri, Dec 2, 2016 at 9:41 PM, Yaniv Kaul  wrote:
>
>>
>>
>> On Dec 2, 2016 2:11 PM, "Anton Marchukov"  wrote:
>>
>> Hello Martin.
>>
>> Do by outdated you mean the old libvirt? If so that is that livirt
>> available in CentOS 7.2? There is no 7.3 yet.
>>
>>
>> Right, this is the issue.
>> Y.
>>
>>
>> Anton.
>>
>> On Fri, Dec 2, 2016 at 1:07 PM, Martin Polednik 
>> wrote:
>>
>>> On 02/12/16 10:55 +0100, Anton Marchukov wrote:
>>>
 Hello All.

 Engine log can be viewed here:

 http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_ma
 ster/3838/artifact/exported-artifacts/basic_suite_master.sh-
 el7/exported-artifacts/test_logs/basic-suite-master/post-004
 _basic_sanity.py/lago-basic-suite-master-engine/_var_log_ovi
 rt-engine/engine.log

 I see the following exception there:

 2016-12-02 04:29:24,030-05 DEBUG
 [org.ovirt.vdsm.jsonrpc.client.internal.ResponseWorker]
 (ResponseWorker) [83b6b5d] Message received: {"jsonrpc": "2.0", "id":
 "ec254aad-441b-47e7-a644-aebddcc1d62c", "result": true}
 2016-12-02 04:29:24,030-05 ERROR
 [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker)
 [83b6b5d] Not able to update response for
 "ec254aad-441b-47e7-a644-aebddcc1d62c"
 2016-12-02 04:29:24,041-05 DEBUG
 [org.ovirt.engine.core.utils.timer.FixedDelayJobListener]
 (DefaultQuartzScheduler3) [47a31d72] Rescheduling
 DEFAULT.org.ovirt.engine.core.bll.gluster.GlusterSyncJob.ref
 reshLightWeightData#-9223372036854775775
 as there is no unfired trigger.
 2016-12-02 04:29:24,024-05 DEBUG
 [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default
 task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] Exception:
 org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException:
 VDSGenericException: VDSNetworkException: Timeout during xml-rpc call
 at org.ovirt.engine.core.vdsbroker.vdsbroker.FutureVDSCommand.g
 et(FutureVDSCommand.java:73)
 [vdsbroker.jar:]

 ...

 2016-12-02 04:29:24,042-05 ERROR
 [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default
 task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] Timeout waiting for
 VDSM response: Internal timeout occured
 2016-12-02 04:29:24,044-05 DEBUG
 [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand]
 (default task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] START,
 GetCapabilitiesVDSCommand(HostName = lago-basic-suite-master-host0,
 VdsIdAndVdsVDSCommandParametersBase:{runAsync='true',
 hostId='5eb7019e-28a3-4f93-9188-685b6c64a2f5',
 vds='Host[lago-basic-suite-master-host0,5eb7019e-28a3-4f93-9
 188-685b6c64a2f5]'}),
 log id: 58f448b8
 2016-12-02 04:29:24,044-05 DEBUG
 [org.ovirt.vdsm.jsonrpc.client.reactors.stomp.impl.Message] (default
 task-12) [d932871a-af4f-4fc9-9ee5-f7a0126a7b85] SEND
 destination:jms.topic.vdsm_requests
 reply-to:jms.topic.vdsm_responses
 content-length:105


 Please note that this runs on localhost with local bridge. So it is not
 likely to be network itself.

>>>
>>> The main issue I see is that the VM run command has actually failed
>>> due to libvirt no accepting /dev/urandom as RNG source[1]. This was
>>> done as engine patch and according to git log, posted around Mon Nov
>>> 28. Also adding Jakub - this should either not happen from engine's
>>> point of view or the lago host is outdated.
>>>
>>> [1]
>>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_ma
>>> ster/3838/artifact/exported-artifacts/basic_suite_master.sh-
>>> el7/exported-artifacts/test_logs/basic-suite-master/post-004
>>> _basic_sanity.py/lago-basic-suite-master-host0/_var_log_vdsm/vdsm.log
>>>
>>>
>>> Anton.

 On Fri, Dec 2, 2016 at 10:43 AM, Anton Marchukov 
 wrote:

 FYI. Experimental flow for master currently fails to run a VM. The tests
> times out while waiting for 180 seconds:
>
> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_
> master/3838/testReport/(root)/004_basic_sanity/vm_run/
>
> This is reproducible over 23 runs of this happened tonight, sounds
> like a
> regression to me:
>
> 

[JIRA] (OVIRT-900) Re: Rebase over other author's patch cannot be pushed to gerrit

[eyal edri [Administrator] (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23821#comment-23821
 ] 

eyal edri [Administrator] commented on OVIRT-900:
-

OK, so as I suggested its best to verify the list of people in those groups and 
add/remove people who are missing.

> Re: Rebase over other author's patch cannot be pushed to gerrit
> ---
>
> Key: OVIRT-900
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-900
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: Barak Korren
>Assignee: Shlomo Ben David
>
> Forwarding to infra-support.
> On 1 December 2016 at 18:03, Yaniv Bronheim  wrote:
> > Not sure since when it was changed, but I noticed that I can't push patches
> > if I'm not the author
> >
> > Counting objects: 50, done.
> > Delta compression using up to 4 threads.
> > Compressing objects: 100% (50/50), done.
> > Writing objects: 100% (50/50), 36.66 KiB | 0 bytes/s, done.
> > Total 50 (delta 34), reused 0 (delta 0)
> > remote: Resolving deltas: 100% (34/34)
> > remote: Processing changes: refs: 1, done
> > remote:
> > remote: ERROR:  In commit db14ec7c1555a9eb37a0fb931bbb4ebdfc674bb4
> > remote: ERROR:  author email address rnach...@redhat.com
> > remote: ERROR:  does not match your user account.
> > remote: ERROR:
> > remote: ERROR:  The following addresses are currently registered:
> > remote: ERROR:bronh...@gmail.com
> > remote: ERROR:ybron...@redhat.com
> > remote: ERROR:
> > remote: ERROR:  To register an email address, please visit:
> > remote: ERROR:  https://gerrit.ovirt.org/#/settings/contact
> > remote:
> > remote:
> > To ssh://ybron...@gerrit.ovirt.org:29418/vdsm
> >  ! [remote rejected] HEAD -> refs/for/master (invalid author)
> > error: failed to push some refs to
> > 'ssh://ybron...@gerrit.ovirt.org:29418/vdsm'
> >
> > We must have permissions to do that, this is part of the rebasing part, and
> > I think its fine to fix patches on behalf of someone else.. but its not the
> > best practice for reviewing.
> > anyway, please undo this change, unless its something that related only to
> > my env.. let me know
> >
> > Thanks
> >
> > --
> > Yaniv Bronhaim.
> >
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> -- 
> Barak Korren
> bkor...@redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-900) Re: Rebase over other author's patch cannot be pushed to gerrit

[Shlomo Ben David (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23820#comment-23820
 ] 

Shlomo Ben David commented on OVIRT-900:


Only the 'vdsm-master-maintainers' group have full permissions on the master 
branch (and 'vdsm-maintainers' group as the owner of the project)
The user has permission as a registered user: push, verify, code-review on the 
'master' branch because he is not a member of that group.

> Re: Rebase over other author's patch cannot be pushed to gerrit
> ---
>
> Key: OVIRT-900
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-900
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: Barak Korren
>Assignee: Shlomo Ben David
>
> Forwarding to infra-support.
> On 1 December 2016 at 18:03, Yaniv Bronheim  wrote:
> > Not sure since when it was changed, but I noticed that I can't push patches
> > if I'm not the author
> >
> > Counting objects: 50, done.
> > Delta compression using up to 4 threads.
> > Compressing objects: 100% (50/50), done.
> > Writing objects: 100% (50/50), 36.66 KiB | 0 bytes/s, done.
> > Total 50 (delta 34), reused 0 (delta 0)
> > remote: Resolving deltas: 100% (34/34)
> > remote: Processing changes: refs: 1, done
> > remote:
> > remote: ERROR:  In commit db14ec7c1555a9eb37a0fb931bbb4ebdfc674bb4
> > remote: ERROR:  author email address rnach...@redhat.com
> > remote: ERROR:  does not match your user account.
> > remote: ERROR:
> > remote: ERROR:  The following addresses are currently registered:
> > remote: ERROR:bronh...@gmail.com
> > remote: ERROR:ybron...@redhat.com
> > remote: ERROR:
> > remote: ERROR:  To register an email address, please visit:
> > remote: ERROR:  https://gerrit.ovirt.org/#/settings/contact
> > remote:
> > remote:
> > To ssh://ybron...@gerrit.ovirt.org:29418/vdsm
> >  ! [remote rejected] HEAD -> refs/for/master (invalid author)
> > error: failed to push some refs to
> > 'ssh://ybron...@gerrit.ovirt.org:29418/vdsm'
> >
> > We must have permissions to do that, this is part of the rebasing part, and
> > I think its fine to fix patches on behalf of someone else.. but its not the
> > best practice for reviewing.
> > anyway, please undo this change, unless its something that related only to
> > my env.. let me know
> >
> > Thanks
> >
> > --
> > Yaniv Bronhaim.
> >
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> -- 
> Barak Korren
> bkor...@redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-903) master-to-master CI upgrade tests

[eyal edri [Administrator] (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23819#comment-23819
 ] 

eyal edri [Administrator] commented on OVIRT-903:
-

Also, you might want to change the ticket name for " fixing/updating
upgrade job" the current title is misleading

On Sun, Dec 4, 2016 at 1:11 PM, eyal edri [Administrator] (oVirt JIRA) <



-- 
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)


> master-to-master CI upgrade tests
> -
>
> Key: OVIRT-903
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-903
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: Yedidyah Bar David
>Assignee: infra
>
> Hi all,
> Recently a patch to the engine [1] added a new package,
> with a certain set of dependencies, which broke upgrade.
> This is similar to [2] but for a new package.
> CI wasn't affected, I think because of [3].
> To make CI test such flows, we should have a job that:
> 1. Builds, installs and sets up the version we want to test
> 2. Pushes a dummy change to the local git repo (to force
> a new version), build the patched tree, create a yum repo
> with the build and add it to yum.repos.d.
> 3. yum update
> 4. engine-setup
> Another option is to revert [3], or to duplicate - have
> both "upgrade current to self" and "upgrade latest snapshot
> to current". The downside is that it will be checked later
> than above plan - instead of in the same build, will only
> be tested in the first build that uses the snapshot after
> it was updated, and also will be misleading, as the reason
> why that job failed will not be apparent (which was why
> [3] was added).
> Please handle. I can of course try to help. Best,
> [1] https://gerrit.ovirt.org/66999
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1321249
> [3] https://gerrit.ovirt.org/67263
> -- 
> Didi



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [JIRA] (OVIRT-903) master-to-master CI upgrade tests

[Eyal Edri]

Also, you might want to change the ticket name for " fixing/updating
upgrade job" the current title is misleading

On Sun, Dec 4, 2016 at 1:11 PM, eyal edri [Administrator] (oVirt JIRA) <
j...@ovirt-jira.atlassian.net> wrote:

>
> [ https://ovirt-jira.atlassian.net/browse/OVIRT-903?page=com.
> atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=23818#comment-23818 ]
>
> eyal edri [Administrator] commented on OVIRT-903:
> -
>
> well,  depending on the amount of effort  needed to update the job,  we
> might want to wait with it until the jobs are moved to an ost suit,  which
> is in progress.
>
> On Dec 4, 2016 13:07, "Yedidyah Bar David"  wrote:
>
> On Sun, Dec 4, 2016 at 11:06 AM, eyal edri [Administrator] (oVirt
> atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=23805#comment-23805 ]
> from-master_el7_merged/
>
> Indeed, and I explained in the ticket why it's not enough as-is.
>
> Best,
> --
> Didi
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
>
> > master-to-master CI upgrade tests
> > -
> >
> > Key: OVIRT-903
> > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-903
> > Project: oVirt - virtualization made easy
> >  Issue Type: By-EMAIL
> >Reporter: Yedidyah Bar David
> >Assignee: infra
> >
> > Hi all,
> > Recently a patch to the engine [1] added a new package,
> > with a certain set of dependencies, which broke upgrade.
> > This is similar to [2] but for a new package.
> > CI wasn't affected, I think because of [3].
> > To make CI test such flows, we should have a job that:
> > 1. Builds, installs and sets up the version we want to test
> > 2. Pushes a dummy change to the local git repo (to force
> > a new version), build the patched tree, create a yum repo
> > with the build and add it to yum.repos.d.
> > 3. yum update
> > 4. engine-setup
> > Another option is to revert [3], or to duplicate - have
> > both "upgrade current to self" and "upgrade latest snapshot
> > to current". The downside is that it will be checked later
> > than above plan - instead of in the same build, will only
> > be tested in the first build that uses the snapshot after
> > it was updated, and also will be misleading, as the reason
> > why that job failed will not be apparent (which was why
> > [3] was added).
> > Please handle. I can of course try to help. Best,
> > [1] https://gerrit.ovirt.org/66999
> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1321249
> > [3] https://gerrit.ovirt.org/67263
> > --
> > Didi
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v1000.610.2#100023)
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
>
>


-- 
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-903) master-to-master CI upgrade tests

[eyal edri [Administrator] (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23818#comment-23818
 ] 

eyal edri [Administrator] commented on OVIRT-903:
-

well,  depending on the amount of effort  needed to update the job,  we
might want to wait with it until the jobs are moved to an ost suit,  which
is in progress.

On Dec 4, 2016 13:07, "Yedidyah Bar David"  wrote:

On Sun, Dec 4, 2016 at 11:06 AM, eyal edri [Administrator] (oVirt
atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel=23805#comment-23805 ]
from-master_el7_merged/

Indeed, and I explained in the ticket why it's not enough as-is.

Best,
--
Didi
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


> master-to-master CI upgrade tests
> -
>
> Key: OVIRT-903
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-903
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: Yedidyah Bar David
>Assignee: infra
>
> Hi all,
> Recently a patch to the engine [1] added a new package,
> with a certain set of dependencies, which broke upgrade.
> This is similar to [2] but for a new package.
> CI wasn't affected, I think because of [3].
> To make CI test such flows, we should have a job that:
> 1. Builds, installs and sets up the version we want to test
> 2. Pushes a dummy change to the local git repo (to force
> a new version), build the patched tree, create a yum repo
> with the build and add it to yum.repos.d.
> 3. yum update
> 4. engine-setup
> Another option is to revert [3], or to duplicate - have
> both "upgrade current to self" and "upgrade latest snapshot
> to current". The downside is that it will be checked later
> than above plan - instead of in the same build, will only
> be tested in the first build that uses the snapshot after
> it was updated, and also will be misleading, as the reason
> why that job failed will not be apparent (which was why
> [3] was added).
> Please handle. I can of course try to help. Best,
> [1] https://gerrit.ovirt.org/66999
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1321249
> [3] https://gerrit.ovirt.org/67263
> -- 
> Didi



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [JIRA] (OVIRT-903) master-to-master CI upgrade tests

[Eyal Edri]

well,  depending on the amount of effort  needed to update the job,  we
might want to wait with it until the jobs are moved to an ost suit,  which
is in progress.

On Dec 4, 2016 13:07, "Yedidyah Bar David"  wrote:

On Sun, Dec 4, 2016 at 11:06 AM, eyal edri [Administrator] (oVirt
JIRA)  wrote:
>
> [ https://ovirt-jira.atlassian.net/browse/OVIRT-903?page=com.
atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel=23805#comment-23805 ]
>
> eyal edri [Administrator] commented on OVIRT-903:
> -
>
> We have master->master upgrade job:
> http://jenkins.ovirt.org/job/ovirt-engine_master_upgrade-
from-master_el7_merged/

Indeed, and I explained in the ticket why it's not enough as-is.

Best,
--
Didi
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-903) master-to-master CI upgrade tests

[Yedidyah Bar David (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23817#comment-23817
 ] 

Yedidyah Bar David commented on OVIRT-903:
--

On Sun, Dec 4, 2016 at 11:06 AM, eyal edri [Administrator] (oVirt

Indeed, and I explained in the ticket why it's not enough as-is.

Best,
-- 
Didi


> master-to-master CI upgrade tests
> -
>
> Key: OVIRT-903
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-903
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: Yedidyah Bar David
>Assignee: infra
>
> Hi all,
> Recently a patch to the engine [1] added a new package,
> with a certain set of dependencies, which broke upgrade.
> This is similar to [2] but for a new package.
> CI wasn't affected, I think because of [3].
> To make CI test such flows, we should have a job that:
> 1. Builds, installs and sets up the version we want to test
> 2. Pushes a dummy change to the local git repo (to force
> a new version), build the patched tree, create a yum repo
> with the build and add it to yum.repos.d.
> 3. yum update
> 4. engine-setup
> Another option is to revert [3], or to duplicate - have
> both "upgrade current to self" and "upgrade latest snapshot
> to current". The downside is that it will be checked later
> than above plan - instead of in the same build, will only
> be tested in the first build that uses the snapshot after
> it was updated, and also will be misleading, as the reason
> why that job failed will not be apparent (which was why
> [3] was added).
> Please handle. I can of course try to help. Best,
> [1] https://gerrit.ovirt.org/66999
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1321249
> [3] https://gerrit.ovirt.org/67263
> -- 
> Didi



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [JIRA] (OVIRT-903) master-to-master CI upgrade tests

[Yedidyah Bar David]

On Sun, Dec 4, 2016 at 11:06 AM, eyal edri [Administrator] (oVirt
JIRA)  wrote:
>
> [ 
> https://ovirt-jira.atlassian.net/browse/OVIRT-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23805#comment-23805
>  ]
>
> eyal edri [Administrator] commented on OVIRT-903:
> -
>
> We have master->master upgrade job:
> http://jenkins.ovirt.org/job/ovirt-engine_master_upgrade-from-master_el7_merged/

Indeed, and I explained in the ticket why it's not enough as-is.

Best,
-- 
Didi
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3898 - FAILURE!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3898/,
Build Number: 3898,
Build Status: FAILURE___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-900) Re: Rebase over other author's patch cannot be pushed to gerrit

[eyal edri [Administrator] (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23815#comment-23815
 ] 

eyal edri [Administrator] commented on OVIRT-900:
-

If he has merge rights on master, then yes. 
Maybe its a good idea to ask the vdsm maintainers who should have merge rights 
on master ( i.e belongs in the master maintainers group )

> Re: Rebase over other author's patch cannot be pushed to gerrit
> ---
>
> Key: OVIRT-900
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-900
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: Barak Korren
>Assignee: Shlomo Ben David
>
> Forwarding to infra-support.
> On 1 December 2016 at 18:03, Yaniv Bronheim  wrote:
> > Not sure since when it was changed, but I noticed that I can't push patches
> > if I'm not the author
> >
> > Counting objects: 50, done.
> > Delta compression using up to 4 threads.
> > Compressing objects: 100% (50/50), done.
> > Writing objects: 100% (50/50), 36.66 KiB | 0 bytes/s, done.
> > Total 50 (delta 34), reused 0 (delta 0)
> > remote: Resolving deltas: 100% (34/34)
> > remote: Processing changes: refs: 1, done
> > remote:
> > remote: ERROR:  In commit db14ec7c1555a9eb37a0fb931bbb4ebdfc674bb4
> > remote: ERROR:  author email address rnach...@redhat.com
> > remote: ERROR:  does not match your user account.
> > remote: ERROR:
> > remote: ERROR:  The following addresses are currently registered:
> > remote: ERROR:bronh...@gmail.com
> > remote: ERROR:ybron...@redhat.com
> > remote: ERROR:
> > remote: ERROR:  To register an email address, please visit:
> > remote: ERROR:  https://gerrit.ovirt.org/#/settings/contact
> > remote:
> > remote:
> > To ssh://ybron...@gerrit.ovirt.org:29418/vdsm
> >  ! [remote rejected] HEAD -> refs/for/master (invalid author)
> > error: failed to push some refs to
> > 'ssh://ybron...@gerrit.ovirt.org:29418/vdsm'
> >
> > We must have permissions to do that, this is part of the rebasing part, and
> > I think its fine to fix patches on behalf of someone else.. but its not the
> > best practice for reviewing.
> > anyway, please undo this change, unless its something that related only to
> > my env.. let me know
> >
> > Thanks
> >
> > --
> > Yaniv Bronhaim.
> >
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> -- 
> Barak Korren
> bkor...@redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-870) Access to artifactory.ovirt.org is slow

[eyal edri [Administrator] (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23814#comment-23814
 ] 

eyal edri [Administrator] commented on OVIRT-870:
-

[~gshinar] Did we solved the slowness issue on artifactory?

> Access to artifactory.ovirt.org is slow
> ---
>
> Key: OVIRT-870
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-870
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: Juan Hernández
>Assignee: infra
>
> Access to artifactory.ovirt.org seems to be very slow now. For example,
> in the following build:
> http://jenkins.ovirt.org/job/ovirt-engine-api-model_master_check-patch-fc24-x86_64/217/consoleText
> It is responding with a transfer rate of 0.2 KiB per second:
>   Downloaded:
> http://artifactory.ovirt.org/artifactory/ovirt-mirror/org/apache/maven/plugins/maven-source-plugin/2.4/maven-source-plugin-2.4.pom
> (7 KB at 0.2 KB/sec)
> Can this be improved?
> -- 
> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> 3ºD, 28016 Madrid, Spain
> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-856) Re: Jenkins permissions required

[eyal edri [Administrator] (oVirt JIRA)]

 [ 
https://ovirt-jira.atlassian.net/browse/OVIRT-856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

eyal edri [Administrator] updated OVIRT-856:

Resolution: Fixed
Status: Done  (was: To Do)

> Re: Jenkins permissions required
> 
>
> Key: OVIRT-856
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-856
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: eyal edri [Administrator]
>Assignee: infra
>
> On Nov 20, 2016 12:43, "Yanir Quinn"  wrote:
> > Hi,
> > I require Jenkins permissions on the following instances in order to
> > create my own custom builds (run Build with Parameters):
> >
> > http://jenkins.ovirt.org/job/ovirt-engine_4.0_build-
> > artifacts-el7-x86_64-manual/
> >
> > http://jenkins.ovirt.org/job/ovirt-engine_master_build-
> > artifacts-el7-x86_64_build_from_patch/
> >
> > my user name is : yquinn
> >
> > Thank you
> > Yanir Quinn
> >
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> >



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-896) Re: Jenkins issues

[eyal edri [Administrator] (oVirt JIRA)]

 [ 
https://ovirt-jira.atlassian.net/browse/OVIRT-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

eyal edri [Administrator] reassigned OVIRT-896:
---

Assignee: Shlomo Ben David  (was: infra)

Please try to help [~fdeutsch] debug the issue

> Re: Jenkins issues
> --
>
> Key: OVIRT-896
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-896
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: eyal edri [Administrator]
>Assignee: Shlomo Ben David
>
> better to send such info to infra-support to document as a ticket. ( adding
> infra-support )
> On Thu, Dec 1, 2016 at 12:22 PM, Fabian Deutsch  wrote:
> > Hey,
> >
> > so - I have an issue
> > this job:
> > is often picking a wrong commit!
> > http://jenkins.ovirt.org/user/fabiand/my-views/view/ovirt-
> > node-ng/job/ovirt-node-ng_master_build-artifacts-el7-
> > x86_64/219/consoleFull
> >
> > It says it resetted to master, but master is actually a different commit.
> > I observed this a few times in the recent days.
> >
> > Does somebody have an idea why this could be happening?
> >
> > 00:00:02.156 Checking out Revision
> > c1970c6f7a6404e8ab030147eec81233905345cf (origin/master)
> >
> > on my local host:
> > $ git rev-parse FETCH_HEAD^{commit} # timeout=10
> > 9123c1fd3ce15b02f2e69efdc367ae1477193aef
> >
> > c1970c6f7a6404e8ab030147eec81233905345cf -- does actually no exist (in
> > my history)
> >
> > - fabian
> >
> -- 
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-871) unrelated CI failure

[eyal edri [Administrator] (oVirt JIRA)]

 [ 
https://ovirt-jira.atlassian.net/browse/OVIRT-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

eyal edri [Administrator] updated OVIRT-871:

Resolution: Fixed
Status: Done  (was: To Do)

We had an issue with the artifactory server which was resolved.

> unrelated CI failure
> 
>
> Key: OVIRT-871
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-871
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: danken
>Assignee: infra
>
> Change https://gerrit.ovirt.org/#/c/67101/ just failed on
> http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch-fc24-x86_64/8031/consoleText
> which I believe is utterly unrelated to the patch. please resolved the 
> underlying problem.
> [ERROR] Failed to execute goal on project restapi-definition: Could not 
> resolve dependencies for project 
> org.ovirt.engine.api:restapi-definition:jar:4.1.0-SNAPSHOT: Failed to collect 
> dependencies at org.ovirt.engine.api:metamodel-runtime:jar:1.1.8: Failed to 
> read artifact descriptor for 
> org.ovirt.engine.api:metamodel-runtime:jar:1.1.8: Could not transfer artifact 
> org.ovirt.engine.api:metamodel-runtime:pom:1.1.8 from/to 
> ovirt-maven-repository 
> (http://artifactory.ovirt.org/artifactory/ovirt-mirror): Failed to transfer 
> file: 
> http://artifactory.ovirt.org/artifactory/ovirt-mirror/org/ovirt/engine/api/metamodel-runtime/1.1.8/metamodel-runtime-1.1.8.pom.
>  Return code is: 502 , ReasonPhrase:Proxy Error. -> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> [ERROR] 
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]   mvn  -rf :restapi-definition
> Makefile:256: recipe for target 'maven' failed
> make[1]: *** [maven] Error 1
> make[1]: Leaving directory 
> '/home/jenkins/workspace/ovirt-engine_master_check-patch-fc24-x86_64/ovirt-engine/rpmbuild/BUILD/ovirt-engine-4.1.0'
> Makefile:263: recipe for target 'tmp.built' failed
> make: *** [tmp.built] Error 2
> error: Bad exit status from /var/tmp/rpm-tmp.2ykGhi (%build)



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-827) el6 proxy issues

[eyal edri [Administrator] (oVirt JIRA)]

 [ 
https://ovirt-jira.atlassian.net/browse/OVIRT-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

eyal edri [Administrator] updated OVIRT-827:

Resolution: Duplicate
Status: Done  (was: To Do)

https://ovirt-jira.atlassian.net/browse/OVIRT-645

> el6 proxy issues
> 
>
> Key: OVIRT-827
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-827
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: sbonazzo
>Assignee: infra
>
> 3.6 el6 nightly builder is failing downloading rpms, looks like a proxy
> issue:
> http://jenkins.ovirt.org/job/ovirt-engine_3.6_build-artifacts-el6-x86_64/1514/
> DEBUG util.py:421:
> http://proxy.phx.ovirt.org:5000/centos-updates/6/x86_64/Packages/python-libs-2.6.6-66.el6_8.x86_64.rpm:
> [Errno 14] curl#18 - "transfer closed with 5563146 bytes remaining to read"
> DEBUG util.py:421:  Trying other mirror.
> DEBUG util.py:421:
> http://proxy.phx.ovirt.org:5000/centos-updates/6/x86_64/Packages/tzdata-2016h-1.el6.noarch.rpm:
> [Errno 14] curl#18 - "transfer closed with 435320 bytes remaining to read"
> DEBUG util.py:421:  Trying other mirror.
> DEBUG util.py:421:  Error downloading packages:
> DEBUG util.py:421:python-libs-2.6.6-66.el6_8.x86_64: [Errno 256] No
> more mirrors to try.
> DEBUG util.py:421:tzdata-2016h-1.el6.noarch: [Errno 256] No more
> mirrors to try.
> -- 
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-900) Re: Rebase over other author's patch cannot be pushed to gerrit

[Shlomo Ben David (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23809#comment-23809
 ] 

Shlomo Ben David commented on OVIRT-900:


Hi,

Nope, the 'Forge author Identity' is set specifically with the following
permissions:
'vdsm-master-maintainers' group for the 'master' branch
'vdsm-stable-maintainers' group for 'stable' branches


   - The user ybron...@redhat.com is a member of 'vdsm-stable-maintainers'
   and 'vdsm-arch-dependencies' groups
   - The user is not a member of 'vdsm-master-maintainers' group.


Should I add him to the 'vdsm-master-maintainers' group?

Best Regards,

Shlomi Ben-David | DevOps Engineer | Red Hat ISRAEL
RHCSA | RHCE
IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci)

OPEN SOURCE - 1 4 011 && 011 4 1

On Thu, Dec 1, 2016 at 6:17 PM, eyal edri [Administrator] (oVirt JIRA) <



> Re: Rebase over other author's patch cannot be pushed to gerrit
> ---
>
> Key: OVIRT-900
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-900
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: Barak Korren
>Assignee: Shlomo Ben David
>
> Forwarding to infra-support.
> On 1 December 2016 at 18:03, Yaniv Bronheim  wrote:
> > Not sure since when it was changed, but I noticed that I can't push patches
> > if I'm not the author
> >
> > Counting objects: 50, done.
> > Delta compression using up to 4 threads.
> > Compressing objects: 100% (50/50), done.
> > Writing objects: 100% (50/50), 36.66 KiB | 0 bytes/s, done.
> > Total 50 (delta 34), reused 0 (delta 0)
> > remote: Resolving deltas: 100% (34/34)
> > remote: Processing changes: refs: 1, done
> > remote:
> > remote: ERROR:  In commit db14ec7c1555a9eb37a0fb931bbb4ebdfc674bb4
> > remote: ERROR:  author email address rnach...@redhat.com
> > remote: ERROR:  does not match your user account.
> > remote: ERROR:
> > remote: ERROR:  The following addresses are currently registered:
> > remote: ERROR:bronh...@gmail.com
> > remote: ERROR:ybron...@redhat.com
> > remote: ERROR:
> > remote: ERROR:  To register an email address, please visit:
> > remote: ERROR:  https://gerrit.ovirt.org/#/settings/contact
> > remote:
> > remote:
> > To ssh://ybron...@gerrit.ovirt.org:29418/vdsm
> >  ! [remote rejected] HEAD -> refs/for/master (invalid author)
> > error: failed to push some refs to
> > 'ssh://ybron...@gerrit.ovirt.org:29418/vdsm'
> >
> > We must have permissions to do that, this is part of the rebasing part, and
> > I think its fine to fix patches on behalf of someone else.. but its not the
> > best practice for reviewing.
> > anyway, please undo this change, unless its something that related only to
> > my env.. let me know
> >
> > Thanks
> >
> > --
> > Yaniv Bronhaim.
> >
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> -- 
> Barak Korren
> bkor...@redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [JIRA] (OVIRT-900) Re: Rebase over other author's patch cannot be pushed to gerrit

[Shlomo Ben David]

Hi,

Nope, the 'Forge author Identity' is set specifically with the following
permissions:
'vdsm-master-maintainers' group for the 'master' branch
'vdsm-stable-maintainers' group for 'stable' branches


   - The user ybron...@redhat.com is a member of 'vdsm-stable-maintainers'
   and 'vdsm-arch-dependencies' groups
   - The user is not a member of 'vdsm-master-maintainers' group.


Should I add him to the 'vdsm-master-maintainers' group?

Best Regards,

Shlomi Ben-David | DevOps Engineer | Red Hat ISRAEL
RHCSA | RHCE
IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci)

OPEN SOURCE - 1 4 011 && 011 4 1

On Thu, Dec 1, 2016 at 6:17 PM, eyal edri [Administrator] (oVirt JIRA) <
j...@ovirt-jira.atlassian.net> wrote:

>
> [ https://ovirt-jira.atlassian.net/browse/OVIRT-900?page=com.
> atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=23633#comment-23633 ]
>
> eyal edri [Administrator] commented on OVIRT-900:
> -
>
> [~sbend...@redhat.com] maybe missing 'forge author identity' permission
> missing to all 'master branch maintaines'?
>
> > Re: Rebase over other author's patch cannot be pushed to gerrit
> > ---
> >
> > Key: OVIRT-900
> > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-900
> > Project: oVirt - virtualization made easy
> >  Issue Type: By-EMAIL
> >Reporter: Barak Korren
> >Assignee: Shlomo Ben David
> >
> > Forwarding to infra-support.
> > On 1 December 2016 at 18:03, Yaniv Bronheim  wrote:
> > > Not sure since when it was changed, but I noticed that I can't push
> patches
> > > if I'm not the author
> > >
> > > Counting objects: 50, done.
> > > Delta compression using up to 4 threads.
> > > Compressing objects: 100% (50/50), done.
> > > Writing objects: 100% (50/50), 36.66 KiB | 0 bytes/s, done.
> > > Total 50 (delta 34), reused 0 (delta 0)
> > > remote: Resolving deltas: 100% (34/34)
> > > remote: Processing changes: refs: 1, done
> > > remote:
> > > remote: ERROR:  In commit db14ec7c1555a9eb37a0fb931bbb4ebdfc674bb4
> > > remote: ERROR:  author email address rnach...@redhat.com
> > > remote: ERROR:  does not match your user account.
> > > remote: ERROR:
> > > remote: ERROR:  The following addresses are currently registered:
> > > remote: ERROR:bronh...@gmail.com
> > > remote: ERROR:ybron...@redhat.com
> > > remote: ERROR:
> > > remote: ERROR:  To register an email address, please visit:
> > > remote: ERROR:  https://gerrit.ovirt.org/#/settings/contact
> > > remote:
> > > remote:
> > > To ssh://ybron...@gerrit.ovirt.org:29418/vdsm
> > >  ! [remote rejected] HEAD -> refs/for/master (invalid author)
> > > error: failed to push some refs to
> > > 'ssh://ybron...@gerrit.ovirt.org:29418/vdsm'
> > >
> > > We must have permissions to do that, this is part of the rebasing
> part, and
> > > I think its fine to fix patches on behalf of someone else.. but its
> not the
> > > best practice for reviewing.
> > > anyway, please undo this change, unless its something that related
> only to
> > > my env.. let me know
> > >
> > > Thanks
> > >
> > > --
> > > Yaniv Bronhaim.
> > >
> > > ___
> > > Infra mailing list
> > > Infra@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/infra
> > >
> > --
> > Barak Korren
> > bkor...@redhat.com
> > RHCE, RHCi, RHV-DevOps Team
> > https://ifireball.wordpress.com/
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v1000.606.0#100023)
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3897 - FAILURE!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3897/,
Build Number: 3897,
Build Status: FAILURE___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-902) Speed up mock_runner.sh setup time by using caches.

[Barak Korren (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23807#comment-23807
 ] 

Barak Korren commented on OVIRT-902:


[~ykaul] The packages install is done by mock itself during the setup of the 
chroot - so could probably be sped up.

All the rest:
* The pip stuff
* The autogen w/o locale
* other package installs  
All come from inside check_patch.sh (from vdsm repo) so do not belong on this 
ticket.

Having said that, yum in the mock env is running through oVirt's proxy - so not 
really going to the internet (pre-post install script still takt time though 
which is why the mock setup is long).

We could probably find one way or another to make pip go through the proxy too 
to make it a little faster (Maybe export the "_http_proxy_" env var in to the 
mock env .to make scripts able to leverage it).

Looking deeper into our scripts, this can be found in mock_cleanup.sh:

{code}
# remove mock system cache, we will setup proxies to do the caching and this
# takes lots of space between runs
shopt -u nullglob
sudo rm -Rf /var/cache/mock/*
{code}

We probably need need remove that before we can gain any speed ups. But we must 
heed David's warning and make sure we zap the caches frequently enough so we 
don't fill up the slaves.


> Speed up mock_runner.sh setup time by using caches.
> ---
>
> Key: OVIRT-902
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-902
> Project: oVirt - virtualization made easy
>  Issue Type: Improvement
>Reporter: Barak Korren
>Assignee: infra
>Priority: High
>  Labels: mock, mock_runner.sh, standard-ci
>
> We've already known that setting up mock takes a while, but mock has some 
> built-in caching features that should allow us to speed this up.
> We need to ensure those features are enabled by mock_runner.sh. The mock 
> options to look at are:
> * root_cache_enable
> * yum_cache_enable
> Both these options should be set to true in the mock chroot config file.
> We've been using these option downstream in minimead and the vdsm build 
> scripts, so they should be safe to use.



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3896 - FAILURE!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3896/,
Build Number: 3896,
Build Status: FAILURE___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] repos_3.6_check-closure_el7_merged - Build # 104 - Still Failing!

[jenkins]

Project: http://jenkins.ovirt.org/job/repos_3.6_check-closure_el7_merged/ 
Build: http://jenkins.ovirt.org/job/repos_3.6_check-closure_el7_merged/104/
Build Number: 104
Build Status:  Still Failing
Triggered By: Started by timer

-
Changes Since Last Success:
-
Changes for Build #102
No changes

Changes for Build #103
No changes

Changes for Build #104
[Gil Shinar] Using project param for new permutataion does not work

[Gil Shinar] Build of SDK V3 will be published for 4.1




-
Failed Tests:
-
No tests ran. 

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-902) Speed up mock_runner.sh setup time by using caches.

[eyal edri [Administrator] (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23806#comment-23806
 ] 

eyal edri [Administrator] commented on OVIRT-902:
-

I think we see the slowness also on experimental flows, same actions which 
takes a few seconds w/o mock takes 2 min when running with mock runner.
So we should probably give priority to checking the caching options.

> Speed up mock_runner.sh setup time by using caches.
> ---
>
> Key: OVIRT-902
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-902
> Project: oVirt - virtualization made easy
>  Issue Type: Improvement
>Reporter: Barak Korren
>Assignee: infra
>Priority: High
>  Labels: mock, mock_runner.sh, standard-ci
>
> We've already known that setting up mock takes a while, but mock has some 
> built-in caching features that should allow us to speed this up.
> We need to ensure those features are enabled by mock_runner.sh. The mock 
> options to look at are:
> * root_cache_enable
> * yum_cache_enable
> Both these options should be set to true in the mock chroot config file.
> We've been using these option downstream in minimead and the vdsm build 
> scripts, so they should be safe to use.



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-903) master-to-master CI upgrade tests

[eyal edri [Administrator] (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23805#comment-23805
 ] 

eyal edri [Administrator] commented on OVIRT-903:
-

We have master->master upgrade job:
http://jenkins.ovirt.org/job/ovirt-engine_master_upgrade-from-master_el7_merged/

> master-to-master CI upgrade tests
> -
>
> Key: OVIRT-903
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-903
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: Yedidyah Bar David
>Assignee: infra
>
> Hi all,
> Recently a patch to the engine [1] added a new package,
> with a certain set of dependencies, which broke upgrade.
> This is similar to [2] but for a new package.
> CI wasn't affected, I think because of [3].
> To make CI test such flows, we should have a job that:
> 1. Builds, installs and sets up the version we want to test
> 2. Pushes a dummy change to the local git repo (to force
> a new version), build the patched tree, create a yum repo
> with the build and add it to yum.repos.d.
> 3. yum update
> 4. engine-setup
> Another option is to revert [3], or to duplicate - have
> both "upgrade current to self" and "upgrade latest snapshot
> to current". The downside is that it will be checked later
> than above plan - instead of in the same build, will only
> be tested in the first build that uses the snapshot after
> it was updated, and also will be misleading, as the reason
> why that job failed will not be apparent (which was why
> [3] was added).
> Please handle. I can of course try to help. Best,
> [1] https://gerrit.ovirt.org/66999
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1321249
> [3] https://gerrit.ovirt.org/67263
> -- 
> Didi



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-902) Speed up mock_runner.sh setup time by using caches.

[Yaniv Kaul (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23804#comment-23804
 ] 

Yaniv Kaul commented on OVIRT-902:
--

1. I'm not sure if it's here or requires a different ticket, but this is SLOW 
(taken from 
http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/5101/consoleFull
 ):

*00:01:28.338* INFO: installing package(s): autoconf automake gdb git 
libguestfs-tools-c libselinux-python3 libvirt-python3 m2crypto make mom 
openvswitch policycoreutils-python PyYAML python-blivet python-coverage 
python2-decorator python-devel python-inotify python-ioprocess python-mock 
python-netaddr python-pthreading python-setuptools python-six python-requests 
python3-decorator python3-netaddr python3-nose python3-six python3-yaml 
rpm-build sanlock-python sudo yum yum-utils
*00:03:48.999* INFO: None

2:20 to install packages, is VERY slow.


2. Then there are the pip stuff - which probably are also going somewhere off 
to the 'net:
00:03:52.839 + easy_install pip
...
00:03:53.401 + pip install -U tox==2.1.1
...
00:03:55.843   Downloading pluggy-0.3.1-py2.py3-none-any.whl
00:03:55.868 Installing collected packages: virtualenv, py, pluggy, tox
00:03:56.223 Successfully installed pluggy-0.3.1 py-1.4.31 tox-2.1.1 
virtualenv-15.1.0

So only 4 seconds, but probably not needed at all.

3. Why not set locale?
00:03:56.670 + ./autogen.sh --system --enable-hooks --enable-vhostmd
00:03:56.678 perl: warning: Setting locale failed.
00:03:56.678 perl: warning: Please check that your locale settings:
00:03:56.679LANGUAGE = (unset),
00:03:56.679LC_ALL = (unset),
00:03:56.679LANG = "en_US.UTF-8"

4. The 5 seconds here are probably due to slow storage!
00:04:05.096 client/Makefile.am:23: installing 'build-aux/py-compile'
00:04:10.239 Running ./configure with --prefix=/usr --sysconfdir=/etc 
--localstatedir=/var --libdir=/usr/lib64 --enable-hooks --enable-vhostmd

5. This is also going out to the Internet?
00:04:14.989 + debuginfo-install -y python
...
00:04:30.879   glibc-debuginfo-common.x86_64 0:2.23.1-11.fc24 

6. Again some more deps:
00:05:23.621 tox -e tests
00:05:23.912 tests create: 
/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/.tox/tests
00:05:29.991 tests installdeps: nose==1.3.7

7. it's not clear if the nose tests are running in parallel. Is that supported 
by VDSM tests?
8. Not sure what is going on here:
00:09:34.017 + coverage html -d 
/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/exported-artifacts/htmlcov
00:09:49.213 + popd
00:09:49.213 ~
00:09:49.213 + shopt -s extglob
00:09:49.213 + git diff-tree --no-commit-id --name-only -r HEAD
00:09:49.213 + egrep --quiet 'vdsm.spec.in|Makefile.am'
00:19:07.994 Took 915 seconds


> Speed up mock_runner.sh setup time by using caches.
> ---
>
> Key: OVIRT-902
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-902
> Project: oVirt - virtualization made easy
>  Issue Type: Improvement
>Reporter: Barak Korren
>Assignee: infra
>Priority: High
>  Labels: mock, mock_runner.sh, standard-ci
>
> We've already known that setting up mock takes a while, but mock has some 
> built-in caching features that should allow us to speed this up.
> We need to ensure those features are enabled by mock_runner.sh. The mock 
> options to look at are:
> * root_cache_enable
> * yum_cache_enable
> Both these options should be set to true in the mock chroot config file.
> We've been using these option downstream in minimead and the vdsm build 
> scripts, so they should be safe to use.



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-903) master-to-master CI upgrade tests

[Yedidyah Bar David (oVirt JIRA)]

Yedidyah Bar David created OVIRT-903:


 Summary: master-to-master CI upgrade tests
 Key: OVIRT-903
 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-903
 Project: oVirt - virtualization made easy
  Issue Type: By-EMAIL
Reporter: Yedidyah Bar David
Assignee: infra


Hi all,

Recently a patch to the engine [1] added a new package,
with a certain set of dependencies, which broke upgrade.
This is similar to [2] but for a new package.

CI wasn't affected, I think because of [3].

To make CI test such flows, we should have a job that:
1. Builds, installs and sets up the version we want to test
2. Pushes a dummy change to the local git repo (to force
a new version), build the patched tree, create a yum repo
with the build and add it to yum.repos.d.
3. yum update
4. engine-setup

Another option is to revert [3], or to duplicate - have
both "upgrade current to self" and "upgrade latest snapshot
to current". The downside is that it will be checked later
than above plan - instead of in the same build, will only
be tested in the first build that uses the snapshot after
it was updated, and also will be misleading, as the reason
why that job failed will not be apparent (which was why
[3] was added).

Please handle. I can of course try to help. Best,

[1] https://gerrit.ovirt.org/66999
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1321249
[3] https://gerrit.ovirt.org/67263
-- 
Didi



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3895 - FAILURE!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3895/,
Build Number: 3895,
Build Status: FAILURE___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3894 - FAILURE!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3894/,
Build Number: 3894,
Build Status: FAILURE___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-901) bad mirror caused check-merged jobs to fail

[Barak Korren (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23802#comment-23802
 ] 

Barak Korren commented on OVIRT-901:


One approach to setting up a mirror that never fails is to make it 
"transactional" by actually seyting up a whole new mirror every time you sync 
it and then create some kind of a meta-data file that point to where it is.
That way when a job starts running it just takes the latest meta-data  file in 
it is guaranteed that the thing this file points to will never change while the 
job is running.

This doesn't mean that syncing the mirror will be slow, there are quite a few 
things we can do to make it fast:
* Use hardlinks - before running the mirror sync tool (reposync, repoman, 
rsync, etc.) copy the older mirror (by creating hardlinks so the copy is fast) 
to the new location.
* Use LVM snapshots - Always sync the mirror to the same place, but after the 
sync is done, create an LVM snapshot of that place, mount it and put the 
location it is mounted into as the path in the metadata file.
* Use a tool the has this kind of functionality built-in (Katallo/Pulp with 
content views)



> bad mirror caused check-merged jobs to fail
> ---
>
> Key: OVIRT-901
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-901
> Project: oVirt - virtualization made easy
>  Issue Type: Bug
>Reporter: eyal edri [Administrator]
>Assignee: infra
>
> check-merged jobs fails on bad mirrors:
> If we can't defend ourselves from repomd.xml file errors, lets setup a mirror 
> when we control the mirror sync and we can decide on the update times ( maybe 
> even disable jenkins jobs when the update is running to avoid errors )
> http://jenkins.ovirt.org/job/repos_3.6_check-closure_el7_merged/103/console
> 07:35:30 Can't download or revert repomd.xml for check-epel-el7
> 07:35:30 Some dependencies may not be complete for this repository
> 07:35:30 Run as root to get all dependencies or use -t to enable a user temp 
> cache
> 07:35:30 Checking Dependencies
> 07:35:30 failure: 
> repodata/151a911cc4b434fcd135e243eec4a4f1d8c1943595a92e2bb838cda5f03577ff-primary.sqlite.xz
>  from check-epel-el7: [Errno 256] No more mirrors to try.
> 07:35:30 
> http://mirror.switch.ch/ftp/mirror/epel/7/x86_64/repodata/151a911cc4b434fcd135e243eec4a4f1d8c1943595a92e2bb838cda5f03577ff-primary.sqlite.xz:
>  [Errno 14] HTTP Error 404 - Not Found



--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Vdsm tests are 4X times faster on travis

[Barak Korren]

On 3 December 2016 at 21:36, Nir Soffer  wrote:
> HI all,
>
> Watching vdsm travis builds in the last weeks, it is clear that vdsm tests
> on travis are about 4X times faster compared with jenkins builds.
>
> Here is a typical build:
>
> ovirt ci: 
> http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/5101/consoleFull
> travis ci: https://travis-ci.org/nirs/vdsm/builds/179056079
>
> The build took 4:34 on travis, and 19:34 on ovirt ci.

Interesting, thanks for looking at this!

>
> This has a huge impact on vdsm maintainers. Having to wait 20 minutes
> for each patch
> means that we must ignore the ci and merge and hope that previous tests 
> without
> rebasing on master were good enough.
>
> The builds are mostly the same, expect:
>
> - In travis we don't check if the build system was changed and
> packages should be built
>   takes 9:18 minutes in ovirt ci.

Well, I guess the infra team can't help with that, but still, is there
anything we could do at the infrastructure level to speed this up?

> - In travis we don't clean or install anything before the test, we use
> a container with all the
>   available packages, pulled from dockerhub.
>   takes about 3:52 minutes in ovirt ci

Well, I guess this is where we (the infra team) should pay attention.
We do have a plan to switch from mock to Docker at some point
(OVIRT-873 [1]), but it'll take a while until we can make such a large
switch.

It the meantime there may be some low-hanging fruit we can pick to
make things faster. Looking at the same log:

16:03:28 Init took 77 seconds

16:05:50 Install packages took 142 seconds

We may be able to speed those up - looking at the way muck is
configured, we may be running with its caches turned off (I'm not yet
100% sure about this - muck_runner.sh is not the simplest script...).
I've created OVIRT-902 [2] for us to look at this.

> - In travis we don't enable coverage. Running the tests with coverage
> may slow down the tests
>   takes 5:04 minutes in ovirt ci
>   creating the coverage report takes only 15 seconds, not interesting

We can easily check this by just sending a patch with coverage turned
on and then sending another patch set for the same patch with coverage
turned off.

> - In travis we don't cleanup anything after the test
>   this takes 34 seconds in ovirt ci

We can look at speeding this up - or perhaps just change things so
that results are reported as soon as check_patch.sh is done as opposed
to when the Jenkins job is done.
There may be some pitfalls here so I need to think a little more
before I recommend going down this path.

> The biggest problem is the build system check taking 9:18 minutes.
> fixing it will cut the build time in half.

Please try fixing that, or maybe this should just move to build_artifacts.sh?

[1]: https://ovirt-jira.atlassian.net/browse/OVIRT-873
[2]: https://ovirt-jira.atlassian.net/browse/OVIRT-902

-- 
Barak Korren
bkor...@redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra