October 2016 - Infra - oVirt List Archives

[JIRA] (OVIRT-753) ovirt-appliance_master_build-artifacts-el7-x86_64 is ignoring failed commands
by sbonazzo (oVirt JIRA) 07 Oct '16

07 Oct '16

sbonazzo created OVIRT-753: ------------------------------ Summary: ovirt-appliance_master_build-artifacts-el7-x86_64 is ignoring failed commands Key: OVIRT-753 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-753 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: sbonazzo Assignee: infra In: http://jenkins.ovirt.org/job/ovirt-appliance_master_build-artifacts-el7-x86… After appliance shutdown: *00:15:44.383* [[ -n "1" ]] && [[ "$(virt-sparsify --help)" =~ --in-place ]] && ( virt-sparsify --in-place ovirt-engine-appliance.qcow2 ; ln ovirt-engine-appliance.qcow2 ovirt-engine-appliance.qcow2.sparse ; )*00:25:53.734* virt-sparsify: error: libguestfs error: guestfs_launch failed.*00:25:53.735* This usually means the libguestfs appliance failed to start or crashed.*00:25:53.735* See http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs*00:25:53.735* or run 'libguestfs-test-tool' and post the *complete* output into a*00:25:53.735* bug report or message to the libguestfs mailing list. The job should have failed here. Instead, the job continues and fails in a later stage: *00:33:01.284* ls -shal ovirt-engine-appliance.ova*00:33:01.287* 1.4G -rwxr-xr-x. 1 root root 1.4G Oct 6 14:13 ovirt-engine-appliance.ova*00:33:01.288* echo "all" appliance done*00:33:01.290* all appliance done*00:33:01.291* + make check*00:33:01.299* make -f image-tools/build.mk ovirt-engine-appliance-manifest-rpm*00:33:01.305* make[1]: Entering directory `/home/jenkins/workspace/ovirt-appliance_master_build-artifacts-el7-x86_64/ovirt-appliance/engine-appliance'*00:33:01.305* guestfish --ro -i -a ovirt-engine-appliance.qcow2 sh 'rpm -qa | sort -u' > ovirt-engine-appliance-manifest-rpm*00:41:58.044* libguestfs: error: appliance closed the connection unexpectedly.*00:41:58.044* This usually means the libguestfs appliance crashed.*00:41:58.044* See http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs*00:41:58.045* for information about how to debug libguestfs and report bugs.*00:41:58.045* libguestfs: error: guestfs_launch failed.*00:41:58.045* This usually means the libguestfs appliance failed to start or crashed.*00:41:58.045* See http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs*00:41:58.046* or run 'libguestfs-test-tool' and post the *complete* output into a*00:41:58.046* bug report or message to the libguestfs mailing list.*00:41:58.059* make[1]: *** [ovirt-engine-appliance-manifest-rpm] Error 1*00:41:58.059* make[1]: Leaving directory `/home/jenkins/workspace/ovirt-appliance_master_build-artifacts-el7-x86_64/ovirt-appliance/engine-appliance'*00:41:58.060* make: *** [ovirt-engine-appliance-manifest-rpm] Error 2*00:41:58.065* Took 2325 seconds wasting 20 minutes of jenkins slave time testing something already known broken. While working on fixing this job, please investigate while it's failing and open a separate issue or bugzilla for it. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com <https://www.redhat.com/it/about/events/red-hat-open-source-day-2016> -- This message was sent by Atlassian JIRA (v1000.383.2#100014)

1 0

EL7 build issues for vdsm-jsonrpc-java
by Martin Perina 07 Oct '16

07 Oct '16

Hi, could you please take a look at EL7 build issue for patch [1]? Fedora build is OK, so I'm not sure what we missed that EL7 build is still failing ... Thanks Martin [1] https://gerrit.ovirt.org/64481

3 21

[JIRA] (OVIRT-752) Fwd: export ovirt-engine-dashboard gerrit repo to github?
by sbonazzo (oVirt JIRA) 07 Oct '16

07 Oct '16

sbonazzo created OVIRT-752: ------------------------------ Summary: Fwd: export ovirt-engine-dashboard gerrit repo to github? Key: OVIRT-752 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-752 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: sbonazzo Assignee: infra Opening a ticket. Looks like we're missing backup on github for ovirt-dashboard. ---------- Forwarded message ---------- From: Scott Dickerson <sdickers(a)redhat.com> Date: Thu, Oct 6, 2016 at 5:53 PM Subject: export ovirt-engine-dashboard gerrit repo to github? To: infra(a)ovirt.org Hi, What do we need to do in order to get the ovirt-engine-dashboard gerrit repo [1] mirrored/exported out to oVirt's github [2] in the same way ovirt-engine does? [1] - https://gerrit.ovirt.org/gitweb?p=ovirt-engine-dashboard.git;a=summary [2] - https://github.com/oVirt Thanks, Scott -- Scott Dickerson Senior Software Engineer RHEV-M Engineering - UX Team Red Hat, Inc _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com <https://www.redhat.com/it/about/events/red-hat-open-source-day-2016> -- This message was sent by Atlassian JIRA (v1000.383.2#100014)

1 0

oVirt infra daily report - unstable production jobs - 99
by jenkins＠jenkins.phx.ovirt.org 06 Oct '16

06 Oct '16

------=_Part_410_512705133.1475794810617 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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/99//artifact/exported-ar… Cheers, Jenkins ------=_Part_410_512705133.1475794810617 Content-Type: application/octet-stream; name=upstream_report.html Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=upstream_report.html Content-ID: <upstream_report.html> <!DOCTYPE html><head><style type="text/css"> table.gridtable { border-collapse: collapse; table-layout:fixed; width:1600px; font-family: monospace; font-size:13px; } .head { font-size:20px; font-family: arial; } .sub { font-size:18px; background-color:#e5e5e5; font-family: arial; } pre { font-family: monospace; display: inline; white-space: pre-wrap; white-space: -moz-pre-wrap !important; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word; } </style> </head> <body> <table class="gridtable" border=2> <tr><th colspan=2 class=head> RHEVM CI Jenkins Daily Report - 06/10/2016 </th></tr><tr><th colspan=2 class=sub> <font color="blue"><a href="http://jenkins.ovirt.org/">00 Unstable Jobs (Production)</a></font> </th></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-appliance_master_build-artifacts-el7-x86…">ovirt-appliance_master_build-artifacts-el7-x86_64</a> </td><td> 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 <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-node-ng_master_build-artifacts-el7-x86_6…">ovirt-node-ng_master_build-artifacts-el7-x86_64</a> </td><td> 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 <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-4.0-snapshot_build-artifac…">ovirt-node-ng_ovirt-4.0-snapshot_build-artifacts-el7-x86_64</a> </td><td> 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 <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-release_master_build-artifacts-all-x86_6…">ovirt-release_master_build-artifacts-all-x86_64</a> </td><td> 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 <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt_3.6_image-ng-system-tests/">ovirt_3.6_image-ng-system-tests</a> </td><td> 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 <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/repos_master_check-closure_fc24_merged/">repos_master_check-closure_fc24_merged</a> </td><td> 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 <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/vdsm_4.0_check-merged-fc23-x86_64/">vdsm_4.0_check-merged-fc23-x86_64</a> </td><td> 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 <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/vdsm_master_check-merged-el7-x86_64/">vdsm_master_check-merged-el7-x86_64</a> </td><td> 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 <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> ------=_Part_410_512705133.1475794810617--

1 0

export ovirt-engine-dashboard gerrit repo to github?
by Scott Dickerson 06 Oct '16

06 Oct '16

Hi, What do we need to do in order to get the ovirt-engine-dashboard gerrit repo [1] mirrored/exported out to oVirt's github [2] in the same way ovirt-engine does? [1] - https://gerrit.ovirt.org/gitweb?p=ovirt-engine-dashboard.git;a=summary [2] - https://github.com/oVirt Thanks, Scott -- Scott Dickerson Senior Software Engineer RHEV-M Engineering - UX Team Red Hat, Inc

2 1

Jenkins build became unstable: ovirt_4.0_he-system-tests #355
by jenkins＠jenkins.phx.ovirt.org 06 Oct '16

06 Oct '16

See <http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/355/changes>

1 1

[JIRA] (OVIRT-751) Persistent maven caches on the mock slaves
by Gil Shinar (oVirt JIRA) 06 Oct '16

06 Oct '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-751?page=com.atlassian.jira.p… ] Gil Shinar commented on OVIRT-751: ---------------------------------- The default maven's cache is a .m2 folder under the user's home directory so the mount should be: source: <mock user's home>/.m2 destination: <jenkins or root's home>/.m2 Something like that. > Persistent maven caches on the mock slaves > ------------------------------------------ > > Key: OVIRT-751 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-751 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Anton Marchukov > Assignee: infra > > I think we need to design a way to retain maven caches on the mocked jenkins slaves. Currently it is stored inside the mock and thus maven downloads packages from artifactory server each time. > However there is really no reason for that. Maven artifacts are designed to be immutable so once artifact is in the repo there is no trivial way to change it without creating a new version. In fact it should never be needed and the correct solution for that is to always create a new version. > SNAPSHOOT artifacts are in fact timestamped and each one have different file name. It is just not visible since maven automatically takes the latest one. But it is not related to caching as the new snapshoot will be a new artifact still. > So based on that point there is no reason to purge maven cache each time, but there are reasons why not to purge. Not purging them will reduce the build times of all java jobs and also reduce the network traffic we have. -- This message was sent by Atlassian JIRA (v1000.383.2#100014)

1 0

[JIRA] (OVIRT-751) Persistent maven caches on the mock slaves
by Barak Korren (oVirt JIRA) 06 Oct '16

06 Oct '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-751?page=com.atlassian.jira.p… ] Barak Korren edited comment on OVIRT-751 at 10/6/16 3:20 PM: ------------------------------------------------------------- This is something a project can decide to do on its own by simply bind-mounting a known location into the chroot (with the *.mounts file). You can either have a per-job cache by mounting from under $WORKSPACE, or a global per-slave cache by mounting from under /home/jenkins was (Author: bkorren(a)redhat.com) This is something a project can decide to do on its own by simply bind-mounting a known location into the chroot (with the *.mounts) file. You can either have a per-job cache by mounting from under $WORKSPACE, or a global per-slave cache by mounting from under /home/jenkins > Persistent maven caches on the mock slaves > ------------------------------------------ > > Key: OVIRT-751 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-751 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Anton Marchukov > Assignee: infra > > I think we need to design a way to retain maven caches on the mocked jenkins slaves. Currently it is stored inside the mock and thus maven downloads packages from artifactory server each time. > However there is really no reason for that. Maven artifacts are designed to be immutable so once artifact is in the repo there is no trivial way to change it without creating a new version. In fact it should never be needed and the correct solution for that is to always create a new version. > SNAPSHOOT artifacts are in fact timestamped and each one have different file name. It is just not visible since maven automatically takes the latest one. But it is not related to caching as the new snapshoot will be a new artifact still. > So based on that point there is no reason to purge maven cache each time, but there are reasons why not to purge. Not purging them will reduce the build times of all java jobs and also reduce the network traffic we have. -- This message was sent by Atlassian JIRA (v1000.383.2#100014)

1 0

[JIRA] (OVIRT-751) Persistent maven caches on the mock slaves
by Barak Korren (oVirt JIRA) 06 Oct '16

06 Oct '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-751?page=com.atlassian.jira.p… ] Barak Korren commented on OVIRT-751: ------------------------------------ If fact one can just send a patch to engine right now and see of this works and improves anything... > Persistent maven caches on the mock slaves > ------------------------------------------ > > Key: OVIRT-751 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-751 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Anton Marchukov > Assignee: infra > > I think we need to design a way to retain maven caches on the mocked jenkins slaves. Currently it is stored inside the mock and thus maven downloads packages from artifactory server each time. > However there is really no reason for that. Maven artifacts are designed to be immutable so once artifact is in the repo there is no trivial way to change it without creating a new version. In fact it should never be needed and the correct solution for that is to always create a new version. > SNAPSHOOT artifacts are in fact timestamped and each one have different file name. It is just not visible since maven automatically takes the latest one. But it is not related to caching as the new snapshoot will be a new artifact still. > So based on that point there is no reason to purge maven cache each time, but there are reasons why not to purge. Not purging them will reduce the build times of all java jobs and also reduce the network traffic we have. -- This message was sent by Atlassian JIRA (v1000.383.2#100014)

1 0

[JIRA] (OVIRT-751) Persistent maven caches on the mock slaves
by Barak Korren (oVirt JIRA) 06 Oct '16

06 Oct '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-751?page=com.atlassian.jira.p… ] Barak Korren commented on OVIRT-751: ------------------------------------ This is something a project can decide to do on its own by simply bind-mounting a known location into the chroot (with the *.mounts) file. You can either have a per-job cache by mounting from under $WORKSPACE, or a global per-slave cache by mounting from under /home/jenkins > Persistent maven caches on the mock slaves > ------------------------------------------ > > Key: OVIRT-751 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-751 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Anton Marchukov > Assignee: infra > > I think we need to design a way to retain maven caches on the mocked jenkins slaves. Currently it is stored inside the mock and thus maven downloads packages from artifactory server each time. > However there is really no reason for that. Maven artifacts are designed to be immutable so once artifact is in the repo there is no trivial way to change it without creating a new version. In fact it should never be needed and the correct solution for that is to always create a new version. > SNAPSHOOT artifacts are in fact timestamped and each one have different file name. It is just not visible since maven automatically takes the latest one. But it is not related to caching as the new snapshoot will be a new artifact still. > So based on that point there is no reason to purge maven cache each time, but there are reasons why not to purge. Not purging them will reduce the build times of all java jobs and also reduce the network traffic we have. -- This message was sent by Atlassian JIRA (v1000.383.2#100014)

1 0