[JIRA] (OVIRT-753) ovirt-appliance_master_build-artifacts-el7-x86_64 is ignoring failed commands
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-753?page=com.atlassian.jira... ]
eyal edri [Administrator] updated OVIRT-753:
--------------------------------------------
Blocked By: pending response from node team
Status: Blocked (was: To Do)
Should be handled by node team, as the code is in the appliance repo.
> 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-x...
> 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.482.3#100017)
8 years
[JIRA] (OVIRT-753) ovirt-appliance_master_build-artifacts-el7-x86_64 is ignoring failed commands
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-753?page=com.atlassian.jira... ]
eyal edri [Administrator] commented on OVIRT-753:
-------------------------------------------------
[~fdeutsch] I'm guessing Tolik wrote this job? can anyone from the node team have a look and fail early on the code?
> 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-x...
> 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.482.3#100017)
8 years
[JIRA] (OVIRT-751) Persistent maven caches on the mock slaves
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-751?page=com.atlassian.jira... ]
eyal edri [Administrator] commented on OVIRT-751:
-------------------------------------------------
I think we should give it a try for ovirt-engine and be proactive on this, since it also serve us as it will reduce load on network and jenkins server and also reduce feedback time to check-patch jobs.
If its a simple patch, lets just send it and check it out, shouldn't take too much time.
> 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.482.3#100017)
8 years
[JIRA] (OVIRT-757) [VDSM] Add Travis CI to vdsm github project
by danken (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-757?page=com.atlassian.jira... ]
danken commented on OVIRT-757:
------------------------------
It would be Vdsm's unit tests, which are also run by check-patch.
vdsm source tree already has .travis.yml which github uses to trigger
Travis runs
We love jenkins CI and we don't want to replace it, only augment, with
very little cost to the ovirt project.
Travis has a nice look-and-feel; but more importantly, it keeps the
outcome of jobs indefinitely. We'd like to see TravisCI for for the very
same reason we have a github mirror to our gerrit: github provides a
widely-used platform, that might be more approachable to the general
public, even though I personally like it less.
> [VDSM] Add Travis CI to vdsm github project
> -------------------------------------------
>
> Key: OVIRT-757
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-757
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: Nir Soffer
> Assignee: infra
>
> Hi all,
> Vdsm includes now a travis configuration running vdsm tests
> on both Fedora 24 and Centos 7.
> You can see example build shere:
> https://travis-ci.org/nirs/vdsm/builds/166263228
> These builds are currently configured in my private vdsm
> fork on github.
> We want to enable Travis CI service on vdsm github project,
> so each time a patch is merged (sync from gerrit) or each time
> a pull request is submitted, a build is started.
> Developers can use these builds in 2 ways:
> - fork vdsm and enable travis on their fork
> - submit pull requests to get them tested
> When a build fails, travis sends email to the author about the
> failure, this works fine for developers forks without any
> additional configuration.
> You can configure github for us, or give Dan and/or me the
> permissions to configure the github project.
> Cheers,
> Nir
--
This message was sent by Atlassian JIRA
(v1000.482.3#100017)
8 years