- Infra - oVirt List Archives

[JIRA] (OVIRT-761) Re: Do we or can we have Mac OS slaves in Jenkins?
by Juan Hernández (oVirt JIRA) 31 Oct '16

31 Oct '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-761?page=com.atlassian.jira.p… ] Juan Hernández commented on OVIRT-761: -------------------------------------- Thank you very much Barak. I agree, lets test Travis for a while before making any other change. > Re: Do we or can we have Mac OS slaves in Jenkins? > -------------------------------------------------- > > Key: OVIRT-761 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-761 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: Barak Korren > > Opening a ticket. > On Mon, Oct 10, 2016 at 11:44 AM, Juan Hernández <jhernand(a)redhat.com> > wrote: > > Hello, > > > > Part of the Ruby SDK uses native code that needs to be compiled during > > installation of the gem. The Ruby SDK is a requirement of ManageIQ, and > > many ManageIQ developers/users use Mac OS. In the past I had some issues > > with this environment, as the C compiler there behaves in an slightly > > different way than GCC. Those issues were discovered only when the SDK > > was already released. To avoid that I would like to have Jenkins jobs > > building/testing the SDK for Mac OS. Is that possible? Do we have Mac OS > > slaves? If not, can we have them? > > > > Regards, > > Juan Hernandez > > > > -- > > 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. > > _______________________________________________ > > 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.482.3#100017)

1 0

[JIRA] (OVIRT-761) Re: Do we or can we have Mac OS slaves in Jenkins?
by Barak Korren (oVirt JIRA) 31 Oct '16

31 Oct '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-761?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-761: ------------------------------- Status: In Progress (was: To Do) > Re: Do we or can we have Mac OS slaves in Jenkins? > -------------------------------------------------- > > Key: OVIRT-761 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-761 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: Barak Korren > > Opening a ticket. > On Mon, Oct 10, 2016 at 11:44 AM, Juan Hernández <jhernand(a)redhat.com> > wrote: > > Hello, > > > > Part of the Ruby SDK uses native code that needs to be compiled during > > installation of the gem. The Ruby SDK is a requirement of ManageIQ, and > > many ManageIQ developers/users use Mac OS. In the past I had some issues > > with this environment, as the C compiler there behaves in an slightly > > different way than GCC. Those issues were discovered only when the SDK > > was already released. To avoid that I would like to have Jenkins jobs > > building/testing the SDK for Mac OS. Is that possible? Do we have Mac OS > > slaves? If not, can we have them? > > > > Regards, > > Juan Hernandez > > > > -- > > 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. > > _______________________________________________ > > 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.482.3#100017)

1 0

[JIRA] (OVIRT-761) Re: Do we or can we have Mac OS slaves in Jenkins?
by Barak Korren (oVirt JIRA) 31 Oct '16

31 Oct '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-761?page=com.atlassian.jira.p… ] Barak Korren commented on OVIRT-761: ------------------------------------ I've enabled Python and Ruby SDKs in Travis: https://travis-ci.org/oVirt/ovirt-engine-sdk-ruby https://travis-ci.org/oVirt/ovirt-engine-sdk To have a Mac OS X slave we'll need buy/have it donated, Lets see of travis is good enough for now. It should be possible to run Standard-CI scripts from travis to avoid some code duplication. > Re: Do we or can we have Mac OS slaves in Jenkins? > -------------------------------------------------- > > Key: OVIRT-761 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-761 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: Barak Korren > > Opening a ticket. > On Mon, Oct 10, 2016 at 11:44 AM, Juan Hernández <jhernand(a)redhat.com> > wrote: > > Hello, > > > > Part of the Ruby SDK uses native code that needs to be compiled during > > installation of the gem. The Ruby SDK is a requirement of ManageIQ, and > > many ManageIQ developers/users use Mac OS. In the past I had some issues > > with this environment, as the C compiler there behaves in an slightly > > different way than GCC. Those issues were discovered only when the SDK > > was already released. To avoid that I would like to have Jenkins jobs > > building/testing the SDK for Mac OS. Is that possible? Do we have Mac OS > > slaves? If not, can we have them? > > > > Regards, > > Juan Hernandez > > > > -- > > 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. > > _______________________________________________ > > 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.482.3#100017)

1 0

[JIRA] (OVIRT-761) Re: Do we or can we have Mac OS slaves in Jenkins?
by Barak Korren (oVirt JIRA) 31 Oct '16

31 Oct '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-761?page=com.atlassian.jira.p… ] Barak Korren reassigned OVIRT-761: ---------------------------------- Assignee: Barak Korren (was: infra) > Re: Do we or can we have Mac OS slaves in Jenkins? > -------------------------------------------------- > > Key: OVIRT-761 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-761 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: Barak Korren > > Opening a ticket. > On Mon, Oct 10, 2016 at 11:44 AM, Juan Hernández <jhernand(a)redhat.com> > wrote: > > Hello, > > > > Part of the Ruby SDK uses native code that needs to be compiled during > > installation of the gem. The Ruby SDK is a requirement of ManageIQ, and > > many ManageIQ developers/users use Mac OS. In the past I had some issues > > with this environment, as the C compiler there behaves in an slightly > > different way than GCC. Those issues were discovered only when the SDK > > was already released. To avoid that I would like to have Jenkins jobs > > building/testing the SDK for Mac OS. Is that possible? Do we have Mac OS > > slaves? If not, can we have them? > > > > Regards, > > Juan Hernandez > > > > -- > > 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. > > _______________________________________________ > > 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.482.3#100017)

1 0

[JIRA] (OVIRT-761) Re: Do we or can we have Mac OS slaves in Jenkins?
by Juan Hernández (oVirt JIRA) 31 Oct '16

31 Oct '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-761?page=com.atlassian.jira.p… ] Juan Hernández commented on OVIRT-761: -------------------------------------- Not sure what permissions are needed exactly, but I think that those that have "admin" access to the "oVirt" organization can just go to travis-ci.org and enable/disable the projects, it is just a matter of flipping a switch. I'd appreciate someone with that access can do it for the Python and Ruby SDKs, as we had already more than one situation where Mac OS X users complained about build failures. I also suggest to reconsider adding support for Mac OS X to Jenkins. I know that it isn't possible to have a Mac OS X VM, but maybe we could have at least one bare metal Mac OS X slave. > Re: Do we or can we have Mac OS slaves in Jenkins? > -------------------------------------------------- > > Key: OVIRT-761 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-761 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: infra > > Opening a ticket. > On Mon, Oct 10, 2016 at 11:44 AM, Juan Hernández <jhernand(a)redhat.com> > wrote: > > Hello, > > > > Part of the Ruby SDK uses native code that needs to be compiled during > > installation of the gem. The Ruby SDK is a requirement of ManageIQ, and > > many ManageIQ developers/users use Mac OS. In the past I had some issues > > with this environment, as the C compiler there behaves in an slightly > > different way than GCC. Those issues were discovered only when the SDK > > was already released. To avoid that I would like to have Jenkins jobs > > building/testing the SDK for Mac OS. Is that possible? Do we have Mac OS > > slaves? If not, can we have them? > > > > Regards, > > Juan Hernandez > > > > -- > > 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. > > _______________________________________________ > > 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.482.3#100017)

1 0

[JIRA] (OVIRT-753) ovirt-appliance_master_build-artifacts-el7-x86_64 is ignoring failed commands
by eyal edri [Administrator] (oVirt JIRA) 31 Oct '16

31 Oct '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-753?page=com.atlassian.jira.p… ] 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-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.482.3#100017)

1 0

[JIRA] (OVIRT-753) ovirt-appliance_master_build-artifacts-el7-x86_64 is ignoring failed commands
by eyal edri [Administrator] (oVirt JIRA) 31 Oct '16

31 Oct '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-753?page=com.atlassian.jira.p… ] 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-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.482.3#100017)

1 0

[JIRA] (OVIRT-750) Issues with mvn central syncrhronization
by eyal edri [Administrator] (oVirt JIRA) 31 Oct '16

31 Oct '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-750?page=com.atlassian.jira.p… ] eyal edri [Administrator] commented on OVIRT-750: ------------------------------------------------- does it still happen? > Issues with mvn central syncrhronization > ---------------------------------------- > > Key: OVIRT-750 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-750 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Piotr Kliczewski > Assignee: infra > > When I release new version of jsonrpc and update the engine to use it the > build fails and it is required to manually perform refresh of artifactory > cache. -- This message was sent by Atlassian JIRA (v1000.482.3#100017)

1 0

[JIRA] (OVIRT-751) Persistent maven caches on the mock slaves
by eyal edri [Administrator] (oVirt JIRA) 31 Oct '16

31 Oct '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-751?page=com.atlassian.jira.p… ] 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)

1 0

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

31 Oct '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-752?page=com.atlassian.jira.p… ] eyal edri [Administrator] reassigned OVIRT-752: ----------------------------------------------- Assignee: Evgheni Dereveanchin (was: infra) Evgheni, can you have a look at this? I think we documented the procedure on how do to do it here: http://infra-docs.readthedocs.io/en/latest/General/Creating_Gerrit_Projects… > 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: Evgheni Dereveanchin > > 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.482.3#100017)

1 0