Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api
Il 09/12/2014 17:40, Alon Bar-Lev ha scritto: > > > - Original Message - >> From: "Sandro Bonazzola" >> To: "Alon Bar-Lev" , "David Caro" >> Cc: "infra" >> Sent: Tuesday, December 9, 2014 5:02:42 PM >> Subject: Re: fc21-vm06.phx.ovirt.org slave missing >> ovirt-engine-extensions-api >> >> Il 09/12/2014 15:50, Alon Bar-Lev ha scritto: >>> >>> >>> - Original Message - From: "David Caro" To: "Alon Bar-Lev" Cc: "infra" Sent: Tuesday, December 9, 2014 4:47:42 PM Subject: Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api On 12/09, Alon Bar-Lev wrote: > > > - Original Message - >> From: "David Caro" >> To: "Alon Bar-Lev" >> Cc: "infra" >> Sent: Tuesday, December 9, 2014 4:38:43 PM >> Subject: Re: fc21-vm06.phx.ovirt.org slave missing >> ovirt-engine-extensions-api >> >> On 12/09, Alon Bar-Lev wrote: >>> >>> >>> - Original Message - From: "David Caro" To: "Alon Bar-Lev" Cc: "infra" Sent: Tuesday, December 9, 2014 4:31:59 PM Subject: Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api On 12/09, Alon Bar-Lev wrote: > Hi, > > DEBUG util.py:366: Error: No Package found for > ovirt-engine-extensions-api Where is that package and when is it needed? >>> >>> this package is produced (subpackage) of ovirt-engine rpm. >>> it is needed to build all extensions. >> >> So should it be in ovirt-master-snapshor repo? > > sure, how can it be not? > oh! > I understand the confusion... > ovirt-engine-extensions-api-impl provides ovirt-engine-extensions-api :) > it is there... I don't see that package for fc21[1], maybe it's not being generated on ovirt-engine side? >>> >>> hmmm... sandro... do we build engine for fc21? if not probably the >>> extensions should not as well... right? >> >> I was pretty sure to have disabled all aaa f21 builds. >> engine is currently failing build on F21 due to Bug 1163400 - [F21] >> ovirt-engine fails testing searchbackend.SyntaxCheckerTest. >> It would be nice if you can take a look to that too, since if I understood >> correctly the fix you pushed for >> Bug 1171160 - [jre8] >> testFilter(org.ovirt.engine.core.notifier.filter.FirstMatchSimpleFilterTest >> fails >> it may be that this issue is just due to different ordering within some list >> too. > > this issue was resolved. yes 1171160 was resolved. It's 1163400 that still cause engine build failures. > >> >> >>> [1] - http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc21/ > >> >>> The job is already using ovirt-master-snapshot repo for the rpm build (the src-rpm build is not, that's why I ask where is it needed) >>> >>> not sure what src-rpm is in this context :( >> >> >> The job is subdivided in two main sections, creating the src.rpm and >> creating the rpm from it. For the first one is not using mock at all, >> so it's using the deps installed directly in the host it runs on, for >> the second, it's using mock, so it's installing all the deps needed by >> the src.rpm (and maybe more from the job config) inside the mock >> chroot, using the above repo. > > I am unsure why to create src rpm any dependency is required... it should > take spec as-is, no? Some projects like vdsm need some extra dependencies to be able to generate the spec file. I'd be glad if that was not required (only autotools at least). >>> >>> it is not... :) >>> also in vdsm the autotools should be required at build, not to package, >>> this is very strange. >>> the srpm is just archive of spec, tarball and patches. >>> > >> >>> > > Thanks, > > [1] > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-fc21-x86_64_merged/9/artifact/exported-artifacts/root.log > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 >> >> -- >> David Caro >> >> Red Hat S.L. >> Continuous Integration Engineer - EMEA ENG Virtualization R&D >> >> Tel.: +420 532 294 605 >> Email: dc...@redhat.com >> Web: www.redhat.com >> RHT Global #: 82-62605 >> -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420
Re: [OUTAGE] ovirt.org wiki outage report [07/12/14]
- Original Message - > From: "Michael Scherer" > To: infra@ovirt.org > Sent: Monday, December 8, 2014 8:07:33 AM > Subject: Re: [OUTAGE] ovirt.org wiki outage report [07/12/14] > > Le lundi 08 décembre 2014 à 13:28 +0100, Michael Scherer a écrit : > > Le lundi 08 décembre 2014 à 06:23 -0500, Eyal Edri a écrit : > > > > > > - Original Message - > > > > From: "Michael Scherer" > > > > To: infra@ovirt.org > > > > Sent: Monday, December 8, 2014 1:03:01 PM > > > > Subject: Re: [OUTAGE] ovirt.org wiki outage report [07/12/14] > > > > > > > > Le dimanche 07 décembre 2014 à 03:25 -0500, Eyal Edri a écrit : > > > > > fyi, > > > > > > > > > > ovirt.org wiki page was down today from 01:33:07 IST till 10:22 IST. > > > > > > > > > > REASON: > > > > > === > > > > > after logging into the openshift gear, seems like there was 99.9% > > > > > space > > > > > taken. > > > > > > > > > > > > > > > RESOLUTION: > > > > > === > > > > > deleted some logs from $OPENSHIFT_MYSQL_DB_LOG_DIR, and restarted > > > > > mysql > > > > > using 'ctl_app restart'. > > > > > space is still not great - at 84%, so we'll need to think soon how to > > > > > resolve this. > > > > > > > > > > > > > > > > > > > > wiki is up now and seems to working well. > > > > > infra - we should look into migrating to a new gear maybe? or extend > > > > > again > > > > > the existing one. > > > > > > > > Happened again today. > > > > > > > > I still maintain that we should move to a dedicated hosting on the phx2 > > > > cluster :) > > > > ( or request quota extensions ). > > > > > > whether if we'll migrate or not, that will take time and won't happen > > > until the ILO issue will be resolved. > > > for now we need to extend our volume there ASAP, cause it will happen > > > again soon, not too many log files > > > are there to delete/gzip. > > > > Agreed. We did request already a quota extension, IIRC, so I guess that > > was not sufficient ? > > Filled the form to get more, will tell you when I have a response. > -- > Michael Scherer > Open Source and Standards, Sysadmin > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra > Went out again this afternoon (12/9), but managed to squeeze out a little more disk space running rhc app tidy. (Thanks to Jason and Justin for the assist!) If there is any way I can help expedite more disk quota, please let me know! BKP -- Brian Proffitt Community Liaison oVirt Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Requests
On 12/09, Lev Veyde wrote: > Hi Sandro, > > OK, I'll send a patch for the ovirt-guest-tools-iso package spec. to take > care of this. > > Thanks in advance, > Lev Veyde > > On Tue, Dec 9, 2014 at 4:38 PM, Sandro Bonazzola > wrote: > > > Il 09/12/2014 15:32, Lev Veyde ha scritto: > > > Hi, > > > > > > 1) > > > I think that we should remove the older oVirt WGT RPM from the repo for > > all distros. > > > > > > i.e. > > http://resources.ovirt.org/pub/ovirt-3.5/rpm/el7/noarch/ovirt-guest-tools-3.5.0-0.5.master.noarch.rpm > > > > > > The oVirt WGT RPM is currently named ovirt-guest-tools-iso, i.e. > > > > > > > > http://resources.ovirt.org/pub/ovirt-3.5/rpm/el7/noarch/ovirt-guest-tools-iso-3.5-7.noarch.rpm > > > > > > So I think there is no reason to keep an older version in the repo. > > > > > > > I guess we'll need also a change in the spec file for > > ovirt-guest-tools-iso, > > something like: > > Obsoletes: ovirt-guest-tools > > for allowing people who already have ovirt-guest-tools to automatically > > receive the upgrade. > > > > I think we shouldn't remove an officially released rpm. > > > > > > > > 2) > > > We need to a symlink for oVirt WGT, so we could refer to the latest > > version of the package in i.e. wiki pages. > > > > +1 Where do you want it? (which url) > > > > > > > > > > Thanks in advance, > > > Lev Veyde. > > > > > > -- > > Sandro Bonazzola > > Better technology. Faster innovation. Powered by community collaboration. > > See how it works at redhat.com > > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 pgpuGkh5pVp5Y.pgp Description: PGP signature ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api
- Original Message - > From: "David Caro" > To: "Alon Bar-Lev" > Cc: "Sandro Bonazzola" , "infra" > Sent: Tuesday, December 9, 2014 7:04:30 PM > Subject: Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api > > On 12/09, Alon Bar-Lev wrote: > > > > > > - Original Message - > > > From: "David Caro" > > > To: "Alon Bar-Lev" > > > Cc: "Sandro Bonazzola" , "infra" > > > Sent: Tuesday, December 9, 2014 6:45:33 PM > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > ovirt-engine-extensions-api > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > > > > - Original Message - > > > > > From: "David Caro" > > > > > To: "Alon Bar-Lev" > > > > > Cc: "Sandro Bonazzola" , "infra" > > > > > > > > > > Sent: Tuesday, December 9, 2014 4:53:08 PM > > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > > ovirt-engine-extensions-api > > > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > From: "David Caro" > > > > > > > To: "Alon Bar-Lev" > > > > > > > Cc: "infra" > > > > > > > Sent: Tuesday, December 9, 2014 4:47:42 PM > > > > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > > > > ovirt-engine-extensions-api > > > > > > > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > > > From: "David Caro" > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > Cc: "infra" > > > > > > > > > Sent: Tuesday, December 9, 2014 4:38:43 PM > > > > > > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > > > > > > ovirt-engine-extensions-api > > > > > > > > > > > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > > > > > From: "David Caro" > > > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > > > Cc: "infra" > > > > > > > > > > > Sent: Tuesday, December 9, 2014 4:31:59 PM > > > > > > > > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > > > > > > > > ovirt-engine-extensions-api > > > > > > > > > > > > > > > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > DEBUG util.py:366: Error: No Package found for > > > > > > > > > > > > ovirt-engine-extensions-api > > > > > > > > > > > > > > > > > > > > > > Where is that package and when is it needed? > > > > > > > > > > > > > > > > > > > > this package is produced (subpackage) of ovirt-engine rpm. > > > > > > > > > > it is needed to build all extensions. > > > > > > > > > > > > > > > > > > So should it be in ovirt-master-snapshor repo? > > > > > > > > > > > > > > > > sure, how can it be not? > > > > > > > > oh! > > > > > > > > I understand the confusion... > > > > > > > > ovirt-engine-extensions-api-impl provides > > > > > > > > ovirt-engine-extensions-api > > > > > > > > :) > > > > > > > > it is there... > > > > > > > > > > > > > > I don't see that package for fc21[1], maybe it's not being > > > > > > > generated > > > > > > > on > > > > > > > ovirt-engine side? > > > > > > > > > > > > hmmm... sandro... do we build engine for fc21? if not probably the > > > > > > extensions should not as well... right? > > > > > > > > > > > > > > > > > > > > [1] - > > > > > > > http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc21/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The job is already using ovirt-master-snapshot repo for > > > > > > > > > > > the > > > > > > > > > > > rpm > > > > > > > > > > > build > > > > > > > > > > > (the src-rpm build is not, that's why I ask where is it > > > > > > > > > > > needed) > > > > > > > > > > > > > > > > > > > > not sure what src-rpm is in this context :( > > > > > > > > > > > > > > > > > > > > > > > > > > > The job is subdivided in two main sections, creating the > > > > > > > > > src.rpm > > > > > > > > > and > > > > > > > > > creating the rpm from it. For the first one is not using mock > > > > > > > > > at > > > > > > > > > all, > > > > > > > > > so it's using the deps installed directly in the host it runs > > > > > > > > > on, > > > > > > > > > for > > > > > > > > > the second, it's using mock, so it's installing all the deps > > > > > > > > > needed > > > > > > > > > by > > > > > > > > > the src.rpm (and maybe more from the job config) inside the > > > > > > > > > mock > > > > > > > > > chroot, using the above repo. > > > > > > > > > > > > > > > > I am unsure why to create src rpm any dependency is required... > > > > > > > > it > > > > > > > > should > > > > > > > > take spec as-is, no? > > > > > > > > > > > > > > Some projects like vdsm need some extra dependencies to be able > > > > > > > to > > > > > > > generate the spec file. I'd be glad if that was not required > > > > > > > (only > > > > > > > autotools at least). > > > > > >
Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api
On 12/09, Alon Bar-Lev wrote: > > > - Original Message - > > From: "David Caro" > > To: "Alon Bar-Lev" > > Cc: "Sandro Bonazzola" , "infra" > > Sent: Tuesday, December 9, 2014 6:45:33 PM > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > ovirt-engine-extensions-api > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > - Original Message - > > > > From: "David Caro" > > > > To: "Alon Bar-Lev" > > > > Cc: "Sandro Bonazzola" , "infra" > > > > Sent: Tuesday, December 9, 2014 4:53:08 PM > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > ovirt-engine-extensions-api > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > > > > > > > - Original Message - > > > > > > From: "David Caro" > > > > > > To: "Alon Bar-Lev" > > > > > > Cc: "infra" > > > > > > Sent: Tuesday, December 9, 2014 4:47:42 PM > > > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > > > ovirt-engine-extensions-api > > > > > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > > From: "David Caro" > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > Cc: "infra" > > > > > > > > Sent: Tuesday, December 9, 2014 4:38:43 PM > > > > > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > > > > > ovirt-engine-extensions-api > > > > > > > > > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > > > > From: "David Caro" > > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > > Cc: "infra" > > > > > > > > > > Sent: Tuesday, December 9, 2014 4:31:59 PM > > > > > > > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > > > > > > > ovirt-engine-extensions-api > > > > > > > > > > > > > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > DEBUG util.py:366: Error: No Package found for > > > > > > > > > > > ovirt-engine-extensions-api > > > > > > > > > > > > > > > > > > > > Where is that package and when is it needed? > > > > > > > > > > > > > > > > > > this package is produced (subpackage) of ovirt-engine rpm. > > > > > > > > > it is needed to build all extensions. > > > > > > > > > > > > > > > > So should it be in ovirt-master-snapshor repo? > > > > > > > > > > > > > > sure, how can it be not? > > > > > > > oh! > > > > > > > I understand the confusion... > > > > > > > ovirt-engine-extensions-api-impl provides > > > > > > > ovirt-engine-extensions-api > > > > > > > :) > > > > > > > it is there... > > > > > > > > > > > > I don't see that package for fc21[1], maybe it's not being generated > > > > > > on > > > > > > ovirt-engine side? > > > > > > > > > > hmmm... sandro... do we build engine for fc21? if not probably the > > > > > extensions should not as well... right? > > > > > > > > > > > > > > > > > [1] - http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc21/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The job is already using ovirt-master-snapshot repo for the > > > > > > > > > > rpm > > > > > > > > > > build > > > > > > > > > > (the src-rpm build is not, that's why I ask where is it > > > > > > > > > > needed) > > > > > > > > > > > > > > > > > > not sure what src-rpm is in this context :( > > > > > > > > > > > > > > > > > > > > > > > > The job is subdivided in two main sections, creating the src.rpm > > > > > > > > and > > > > > > > > creating the rpm from it. For the first one is not using mock at > > > > > > > > all, > > > > > > > > so it's using the deps installed directly in the host it runs > > > > > > > > on, > > > > > > > > for > > > > > > > > the second, it's using mock, so it's installing all the deps > > > > > > > > needed > > > > > > > > by > > > > > > > > the src.rpm (and maybe more from the job config) inside the mock > > > > > > > > chroot, using the above repo. > > > > > > > > > > > > > > I am unsure why to create src rpm any dependency is required... it > > > > > > > should > > > > > > > take spec as-is, no? > > > > > > > > > > > > Some projects like vdsm need some extra dependencies to be able to > > > > > > generate the spec file. I'd be glad if that was not required (only > > > > > > autotools at least). > > > > > > > > > > it is not... :) > > > > > also in vdsm the autotools should be required at build, not to > > > > > package, > > > > > this is very strange. > > > > > the srpm is just archive of spec, tarball and patches. > > > > > > > > The problem is that the spec on vdsm is a template, and it's generated > > > > with autotools so you need at least autoools to get it, but also it > > > > pulls extra deps in to run make dist (not sure they are actually all > > > > needed though) > > > > > > this is make dist issue not rpmbuild -ts ... :) > > > > yes, it is, but I have to run make dist prior to rpmbuild -ts. So it's > > part of
Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api
- Original Message - > From: "David Caro" > To: "Alon Bar-Lev" > Cc: "Sandro Bonazzola" , "infra" > Sent: Tuesday, December 9, 2014 6:45:33 PM > Subject: Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api > > On 12/09, Alon Bar-Lev wrote: > > > > > > - Original Message - > > > From: "David Caro" > > > To: "Alon Bar-Lev" > > > Cc: "Sandro Bonazzola" , "infra" > > > Sent: Tuesday, December 9, 2014 4:53:08 PM > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > ovirt-engine-extensions-api > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > > > > - Original Message - > > > > > From: "David Caro" > > > > > To: "Alon Bar-Lev" > > > > > Cc: "infra" > > > > > Sent: Tuesday, December 9, 2014 4:47:42 PM > > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > > ovirt-engine-extensions-api > > > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > From: "David Caro" > > > > > > > To: "Alon Bar-Lev" > > > > > > > Cc: "infra" > > > > > > > Sent: Tuesday, December 9, 2014 4:38:43 PM > > > > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > > > > ovirt-engine-extensions-api > > > > > > > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > > > From: "David Caro" > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > Cc: "infra" > > > > > > > > > Sent: Tuesday, December 9, 2014 4:31:59 PM > > > > > > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > > > > > > ovirt-engine-extensions-api > > > > > > > > > > > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > DEBUG util.py:366: Error: No Package found for > > > > > > > > > > ovirt-engine-extensions-api > > > > > > > > > > > > > > > > > > Where is that package and when is it needed? > > > > > > > > > > > > > > > > this package is produced (subpackage) of ovirt-engine rpm. > > > > > > > > it is needed to build all extensions. > > > > > > > > > > > > > > So should it be in ovirt-master-snapshor repo? > > > > > > > > > > > > sure, how can it be not? > > > > > > oh! > > > > > > I understand the confusion... > > > > > > ovirt-engine-extensions-api-impl provides > > > > > > ovirt-engine-extensions-api > > > > > > :) > > > > > > it is there... > > > > > > > > > > I don't see that package for fc21[1], maybe it's not being generated > > > > > on > > > > > ovirt-engine side? > > > > > > > > hmmm... sandro... do we build engine for fc21? if not probably the > > > > extensions should not as well... right? > > > > > > > > > > > > > > [1] - http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc21/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The job is already using ovirt-master-snapshot repo for the > > > > > > > > > rpm > > > > > > > > > build > > > > > > > > > (the src-rpm build is not, that's why I ask where is it > > > > > > > > > needed) > > > > > > > > > > > > > > > > not sure what src-rpm is in this context :( > > > > > > > > > > > > > > > > > > > > > The job is subdivided in two main sections, creating the src.rpm > > > > > > > and > > > > > > > creating the rpm from it. For the first one is not using mock at > > > > > > > all, > > > > > > > so it's using the deps installed directly in the host it runs on, > > > > > > > for > > > > > > > the second, it's using mock, so it's installing all the deps > > > > > > > needed > > > > > > > by > > > > > > > the src.rpm (and maybe more from the job config) inside the mock > > > > > > > chroot, using the above repo. > > > > > > > > > > > > I am unsure why to create src rpm any dependency is required... it > > > > > > should > > > > > > take spec as-is, no? > > > > > > > > > > Some projects like vdsm need some extra dependencies to be able to > > > > > generate the spec file. I'd be glad if that was not required (only > > > > > autotools at least). > > > > > > > > it is not... :) > > > > also in vdsm the autotools should be required at build, not to package, > > > > this is very strange. > > > > the srpm is just archive of spec, tarball and patches. > > > > > > The problem is that the spec on vdsm is a template, and it's generated > > > with autotools so you need at least autoools to get it, but also it > > > pulls extra deps in to run make dist (not sure they are actually all > > > needed though) > > > > this is make dist issue not rpmbuild -ts ... :) > > yes, it is, but I have to run make dist prior to rpmbuild -ts. So it's > part of the problem of getting the src.rpm from the code. well... one time we start to consider tarball as releases... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > >
Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api
On 12/09, Alon Bar-Lev wrote: > > > - Original Message - > > From: "David Caro" > > To: "Alon Bar-Lev" > > Cc: "Sandro Bonazzola" , "infra" > > Sent: Tuesday, December 9, 2014 4:53:08 PM > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > ovirt-engine-extensions-api > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > - Original Message - > > > > From: "David Caro" > > > > To: "Alon Bar-Lev" > > > > Cc: "infra" > > > > Sent: Tuesday, December 9, 2014 4:47:42 PM > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > ovirt-engine-extensions-api > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > > > > > > > - Original Message - > > > > > > From: "David Caro" > > > > > > To: "Alon Bar-Lev" > > > > > > Cc: "infra" > > > > > > Sent: Tuesday, December 9, 2014 4:38:43 PM > > > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > > > ovirt-engine-extensions-api > > > > > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > > From: "David Caro" > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > Cc: "infra" > > > > > > > > Sent: Tuesday, December 9, 2014 4:31:59 PM > > > > > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > > > > > ovirt-engine-extensions-api > > > > > > > > > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > DEBUG util.py:366: Error: No Package found for > > > > > > > > > ovirt-engine-extensions-api > > > > > > > > > > > > > > > > Where is that package and when is it needed? > > > > > > > > > > > > > > this package is produced (subpackage) of ovirt-engine rpm. > > > > > > > it is needed to build all extensions. > > > > > > > > > > > > So should it be in ovirt-master-snapshor repo? > > > > > > > > > > sure, how can it be not? > > > > > oh! > > > > > I understand the confusion... > > > > > ovirt-engine-extensions-api-impl provides ovirt-engine-extensions-api > > > > > :) > > > > > it is there... > > > > > > > > I don't see that package for fc21[1], maybe it's not being generated on > > > > ovirt-engine side? > > > > > > hmmm... sandro... do we build engine for fc21? if not probably the > > > extensions should not as well... right? > > > > > > > > > > > [1] - http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc21/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The job is already using ovirt-master-snapshot repo for the rpm > > > > > > > > build > > > > > > > > (the src-rpm build is not, that's why I ask where is it needed) > > > > > > > > > > > > > > not sure what src-rpm is in this context :( > > > > > > > > > > > > > > > > > > The job is subdivided in two main sections, creating the src.rpm and > > > > > > creating the rpm from it. For the first one is not using mock at > > > > > > all, > > > > > > so it's using the deps installed directly in the host it runs on, > > > > > > for > > > > > > the second, it's using mock, so it's installing all the deps needed > > > > > > by > > > > > > the src.rpm (and maybe more from the job config) inside the mock > > > > > > chroot, using the above repo. > > > > > > > > > > I am unsure why to create src rpm any dependency is required... it > > > > > should > > > > > take spec as-is, no? > > > > > > > > Some projects like vdsm need some extra dependencies to be able to > > > > generate the spec file. I'd be glad if that was not required (only > > > > autotools at least). > > > > > > it is not... :) > > > also in vdsm the autotools should be required at build, not to package, > > > this is very strange. > > > the srpm is just archive of spec, tarball and patches. > > > > The problem is that the spec on vdsm is a template, and it's generated > > with autotools so you need at least autoools to get it, but also it > > pulls extra deps in to run make dist (not sure they are actually all > > needed though) > > this is make dist issue not rpmbuild -ts ... :) yes, it is, but I have to run make dist prior to rpmbuild -ts. So it's part of the problem of getting the src.rpm from the code. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-fc21-x86_64_merged/9/artifact/exported-artifacts/root.log > > > > > > > > > ___ > > > > > > > > > Infra mailing list > > > > > > > > > Infra@ovirt.org > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > > > > > > > > > > -- > > > > > > > > David Caro > > > > > > > > > > > > > > > > Red Hat S.L. > > > > > > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > > > > > > > > > > > Tel.: +420 532 294 605 > > > > > > > > Email: dc...@redhat.com > > > > > > > > Web
Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api
- Original Message - > From: "Sandro Bonazzola" > To: "Alon Bar-Lev" , "David Caro" > Cc: "infra" > Sent: Tuesday, December 9, 2014 5:02:42 PM > Subject: Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api > > Il 09/12/2014 15:50, Alon Bar-Lev ha scritto: > > > > > > - Original Message - > >> From: "David Caro" > >> To: "Alon Bar-Lev" > >> Cc: "infra" > >> Sent: Tuesday, December 9, 2014 4:47:42 PM > >> Subject: Re: fc21-vm06.phx.ovirt.org slave missing > >> ovirt-engine-extensions-api > >> > >> On 12/09, Alon Bar-Lev wrote: > >>> > >>> > >>> - Original Message - > From: "David Caro" > To: "Alon Bar-Lev" > Cc: "infra" > Sent: Tuesday, December 9, 2014 4:38:43 PM > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > ovirt-engine-extensions-api > > On 12/09, Alon Bar-Lev wrote: > > > > > > - Original Message - > >> From: "David Caro" > >> To: "Alon Bar-Lev" > >> Cc: "infra" > >> Sent: Tuesday, December 9, 2014 4:31:59 PM > >> Subject: Re: fc21-vm06.phx.ovirt.org slave missing > >> ovirt-engine-extensions-api > >> > >> On 12/09, Alon Bar-Lev wrote: > >>> Hi, > >>> > >>> DEBUG util.py:366: Error: No Package found for > >>> ovirt-engine-extensions-api > >> > >> Where is that package and when is it needed? > > > > this package is produced (subpackage) of ovirt-engine rpm. > > it is needed to build all extensions. > > So should it be in ovirt-master-snapshor repo? > >>> > >>> sure, how can it be not? > >>> oh! > >>> I understand the confusion... > >>> ovirt-engine-extensions-api-impl provides ovirt-engine-extensions-api :) > >>> it is there... > >> > >> I don't see that package for fc21[1], maybe it's not being generated on > >> ovirt-engine side? > > > > hmmm... sandro... do we build engine for fc21? if not probably the > > extensions should not as well... right? > > I was pretty sure to have disabled all aaa f21 builds. > engine is currently failing build on F21 due to Bug 1163400 - [F21] > ovirt-engine fails testing searchbackend.SyntaxCheckerTest. > It would be nice if you can take a look to that too, since if I understood > correctly the fix you pushed for > Bug 1171160 - [jre8] > testFilter(org.ovirt.engine.core.notifier.filter.FirstMatchSimpleFilterTest > fails > it may be that this issue is just due to different ordering within some list > too. this issue was resolved. > > > > > >> > >> [1] - http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc21/ > >> > >>> > > > > >> The job is already using ovirt-master-snapshot repo for the rpm build > >> (the src-rpm build is not, that's why I ask where is it needed) > > > > not sure what src-rpm is in this context :( > > > The job is subdivided in two main sections, creating the src.rpm and > creating the rpm from it. For the first one is not using mock at all, > so it's using the deps installed directly in the host it runs on, for > the second, it's using mock, so it's installing all the deps needed by > the src.rpm (and maybe more from the job config) inside the mock > chroot, using the above repo. > >>> > >>> I am unsure why to create src rpm any dependency is required... it should > >>> take spec as-is, no? > >> > >> Some projects like vdsm need some extra dependencies to be able to > >> generate the spec file. I'd be glad if that was not required (only > >> autotools at least). > > > > it is not... :) > > also in vdsm the autotools should be required at build, not to package, > > this is very strange. > > the srpm is just archive of spec, tarball and patches. > > > >> > >>> > > > > >> > >>> > >>> Thanks, > >>> > >>> [1] > >>> http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-fc21-x86_64_merged/9/artifact/exported-artifacts/root.log > >>> ___ > >>> Infra mailing list > >>> Infra@ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/infra > >> > >> -- > >> David Caro > >> > >> Red Hat S.L. > >> Continuous Integration Engineer - EMEA ENG Virtualization R&D > >> > >> Tel.: +420 532 294 605 > >> Email: dc...@redhat.com > >> Web: www.redhat.com > >> RHT Global #: 82-62605 > >> > > -- > David Caro > > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > Tel.: +420 532 294 605 > Email: dc...@redhat.com > Web: www.redhat.com > RHT Global #: 82-62605 > > >> > >> -- > >> David Caro > >> > >> Red Hat S.L. > >> Continuous Integration Engineer - EMEA ENG Virtualization R&D > >> > >> Tel.: +420 532 294 605 > >> Email: dc...@redhat.com > >> Web: www.redhat.com > >> RHT Global #: 82-62605 > >> > > > -- > Sandro Bonazzola > Better technology. Fas
Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api
- Original Message - > From: "David Caro" > To: "Alon Bar-Lev" > Cc: "Sandro Bonazzola" , "infra" > Sent: Tuesday, December 9, 2014 4:53:08 PM > Subject: Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api > > On 12/09, Alon Bar-Lev wrote: > > > > > > - Original Message - > > > From: "David Caro" > > > To: "Alon Bar-Lev" > > > Cc: "infra" > > > Sent: Tuesday, December 9, 2014 4:47:42 PM > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > ovirt-engine-extensions-api > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > > > > - Original Message - > > > > > From: "David Caro" > > > > > To: "Alon Bar-Lev" > > > > > Cc: "infra" > > > > > Sent: Tuesday, December 9, 2014 4:38:43 PM > > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > > ovirt-engine-extensions-api > > > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > From: "David Caro" > > > > > > > To: "Alon Bar-Lev" > > > > > > > Cc: "infra" > > > > > > > Sent: Tuesday, December 9, 2014 4:31:59 PM > > > > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > > > > ovirt-engine-extensions-api > > > > > > > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > DEBUG util.py:366: Error: No Package found for > > > > > > > > ovirt-engine-extensions-api > > > > > > > > > > > > > > Where is that package and when is it needed? > > > > > > > > > > > > this package is produced (subpackage) of ovirt-engine rpm. > > > > > > it is needed to build all extensions. > > > > > > > > > > So should it be in ovirt-master-snapshor repo? > > > > > > > > sure, how can it be not? > > > > oh! > > > > I understand the confusion... > > > > ovirt-engine-extensions-api-impl provides ovirt-engine-extensions-api > > > > :) > > > > it is there... > > > > > > I don't see that package for fc21[1], maybe it's not being generated on > > > ovirt-engine side? > > > > hmmm... sandro... do we build engine for fc21? if not probably the > > extensions should not as well... right? > > > > > > > > [1] - http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc21/ > > > > > > > > > > > > > > > > > > > > > > > > > The job is already using ovirt-master-snapshot repo for the rpm > > > > > > > build > > > > > > > (the src-rpm build is not, that's why I ask where is it needed) > > > > > > > > > > > > not sure what src-rpm is in this context :( > > > > > > > > > > > > > > > The job is subdivided in two main sections, creating the src.rpm and > > > > > creating the rpm from it. For the first one is not using mock at all, > > > > > so it's using the deps installed directly in the host it runs on, for > > > > > the second, it's using mock, so it's installing all the deps needed > > > > > by > > > > > the src.rpm (and maybe more from the job config) inside the mock > > > > > chroot, using the above repo. > > > > > > > > I am unsure why to create src rpm any dependency is required... it > > > > should > > > > take spec as-is, no? > > > > > > Some projects like vdsm need some extra dependencies to be able to > > > generate the spec file. I'd be glad if that was not required (only > > > autotools at least). > > > > it is not... :) > > also in vdsm the autotools should be required at build, not to package, > > this is very strange. > > the srpm is just archive of spec, tarball and patches. > > The problem is that the spec on vdsm is a template, and it's generated > with autotools so you need at least autoools to get it, but also it > pulls extra deps in to run make dist (not sure they are actually all > needed though) this is make dist issue not rpmbuild -ts ... :) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > [1] > > > > > > > > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-fc21-x86_64_merged/9/artifact/exported-artifacts/root.log > > > > > > > > ___ > > > > > > > > Infra mailing list > > > > > > > > Infra@ovirt.org > > > > > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > > > > > > > > -- > > > > > > > David Caro > > > > > > > > > > > > > > Red Hat S.L. > > > > > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > > > > > > > > > Tel.: +420 532 294 605 > > > > > > > Email: dc...@redhat.com > > > > > > > Web: www.redhat.com > > > > > > > RHT Global #: 82-62605 > > > > > > > > > > > > > > > > > -- > > > > > David Caro > > > > > > > > > > Red Hat S.L. > > > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > > > > > Tel.: +420 532 294 605 > > > > > Email: dc...@redhat.com > > > > > Web: www.redhat.com > > > > > RHT Global #: 82-62605 > > > > > > > > > > > -- > > > David Caro > > > > > > Red Hat S.L. > > > Continuous Integration En
Re: Requests
Hi Sandro, OK, I'll send a patch for the ovirt-guest-tools-iso package spec. to take care of this. Thanks in advance, Lev Veyde On Tue, Dec 9, 2014 at 4:38 PM, Sandro Bonazzola wrote: > Il 09/12/2014 15:32, Lev Veyde ha scritto: > > Hi, > > > > 1) > > I think that we should remove the older oVirt WGT RPM from the repo for > all distros. > > > > i.e. > http://resources.ovirt.org/pub/ovirt-3.5/rpm/el7/noarch/ovirt-guest-tools-3.5.0-0.5.master.noarch.rpm > > > > The oVirt WGT RPM is currently named ovirt-guest-tools-iso, i.e. > > > > > http://resources.ovirt.org/pub/ovirt-3.5/rpm/el7/noarch/ovirt-guest-tools-iso-3.5-7.noarch.rpm > > > > So I think there is no reason to keep an older version in the repo. > > > > I guess we'll need also a change in the spec file for > ovirt-guest-tools-iso, > something like: > Obsoletes: ovirt-guest-tools > for allowing people who already have ovirt-guest-tools to automatically > receive the upgrade. > > I think we shouldn't remove an officially released rpm. > > > > > 2) > > We need to a symlink for oVirt WGT, so we could refer to the latest > version of the package in i.e. wiki pages. > > +1 > > > > > > Thanks in advance, > > Lev Veyde. > > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
INFRA ISSUE: [oVirt Jenkins] ovirt-engine_3.5_upgrade-from-3.4_merged - Build # 1246 - Failure!
Project: http://jenkins.ovirt.org/job/ovirt-engine_3.5_upgrade-from-3.4_merged/ Build: http://jenkins.ovirt.org/job/ovirt-engine_3.5_upgrade-from-3.4_merged/1246/ Build Number: 1246 Build Status: Failure Triggered By: Triggered by Gerrit: http://gerrit.ovirt.org/36004 - Changes Since Last Success: - Changes for Build #1246 [Yedidyah Bar David] packaging: rename: drop handling of RedirectServletReportsPage - Failed Tests: - No tests ran. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api
Il 09/12/2014 15:50, Alon Bar-Lev ha scritto: > > > - Original Message - >> From: "David Caro" >> To: "Alon Bar-Lev" >> Cc: "infra" >> Sent: Tuesday, December 9, 2014 4:47:42 PM >> Subject: Re: fc21-vm06.phx.ovirt.org slave missing >> ovirt-engine-extensions-api >> >> On 12/09, Alon Bar-Lev wrote: >>> >>> >>> - Original Message - From: "David Caro" To: "Alon Bar-Lev" Cc: "infra" Sent: Tuesday, December 9, 2014 4:38:43 PM Subject: Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api On 12/09, Alon Bar-Lev wrote: > > > - Original Message - >> From: "David Caro" >> To: "Alon Bar-Lev" >> Cc: "infra" >> Sent: Tuesday, December 9, 2014 4:31:59 PM >> Subject: Re: fc21-vm06.phx.ovirt.org slave missing >> ovirt-engine-extensions-api >> >> On 12/09, Alon Bar-Lev wrote: >>> Hi, >>> >>> DEBUG util.py:366: Error: No Package found for >>> ovirt-engine-extensions-api >> >> Where is that package and when is it needed? > > this package is produced (subpackage) of ovirt-engine rpm. > it is needed to build all extensions. So should it be in ovirt-master-snapshor repo? >>> >>> sure, how can it be not? >>> oh! >>> I understand the confusion... >>> ovirt-engine-extensions-api-impl provides ovirt-engine-extensions-api :) >>> it is there... >> >> I don't see that package for fc21[1], maybe it's not being generated on >> ovirt-engine side? > > hmmm... sandro... do we build engine for fc21? if not probably the extensions > should not as well... right? I was pretty sure to have disabled all aaa f21 builds. engine is currently failing build on F21 due to Bug 1163400 - [F21] ovirt-engine fails testing searchbackend.SyntaxCheckerTest. It would be nice if you can take a look to that too, since if I understood correctly the fix you pushed for Bug 1171160 - [jre8] testFilter(org.ovirt.engine.core.notifier.filter.FirstMatchSimpleFilterTest fails it may be that this issue is just due to different ordering within some list too. > >> >> [1] - http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc21/ >> >>> > >> The job is already using ovirt-master-snapshot repo for the rpm build >> (the src-rpm build is not, that's why I ask where is it needed) > > not sure what src-rpm is in this context :( The job is subdivided in two main sections, creating the src.rpm and creating the rpm from it. For the first one is not using mock at all, so it's using the deps installed directly in the host it runs on, for the second, it's using mock, so it's installing all the deps needed by the src.rpm (and maybe more from the job config) inside the mock chroot, using the above repo. >>> >>> I am unsure why to create src rpm any dependency is required... it should >>> take spec as-is, no? >> >> Some projects like vdsm need some extra dependencies to be able to >> generate the spec file. I'd be glad if that was not required (only >> autotools at least). > > it is not... :) > also in vdsm the autotools should be required at build, not to package, this > is very strange. > the srpm is just archive of spec, tarball and patches. > >> >>> > >> >>> >>> Thanks, >>> >>> [1] >>> http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-fc21-x86_64_merged/9/artifact/exported-artifacts/root.log >>> ___ >>> Infra mailing list >>> Infra@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/infra >> >> -- >> David Caro >> >> Red Hat S.L. >> Continuous Integration Engineer - EMEA ENG Virtualization R&D >> >> Tel.: +420 532 294 605 >> Email: dc...@redhat.com >> Web: www.redhat.com >> RHT Global #: 82-62605 >> -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 >> >> -- >> David Caro >> >> Red Hat S.L. >> Continuous Integration Engineer - EMEA ENG Virtualization R&D >> >> Tel.: +420 532 294 605 >> Email: dc...@redhat.com >> Web: www.redhat.com >> RHT Global #: 82-62605 >> -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api
On 12/09, Alon Bar-Lev wrote: > > > - Original Message - > > From: "David Caro" > > To: "Alon Bar-Lev" > > Cc: "infra" > > Sent: Tuesday, December 9, 2014 4:47:42 PM > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > ovirt-engine-extensions-api > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > - Original Message - > > > > From: "David Caro" > > > > To: "Alon Bar-Lev" > > > > Cc: "infra" > > > > Sent: Tuesday, December 9, 2014 4:38:43 PM > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > ovirt-engine-extensions-api > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > > > > > > > - Original Message - > > > > > > From: "David Caro" > > > > > > To: "Alon Bar-Lev" > > > > > > Cc: "infra" > > > > > > Sent: Tuesday, December 9, 2014 4:31:59 PM > > > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > > > ovirt-engine-extensions-api > > > > > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > Hi, > > > > > > > > > > > > > > DEBUG util.py:366: Error: No Package found for > > > > > > > ovirt-engine-extensions-api > > > > > > > > > > > > Where is that package and when is it needed? > > > > > > > > > > this package is produced (subpackage) of ovirt-engine rpm. > > > > > it is needed to build all extensions. > > > > > > > > So should it be in ovirt-master-snapshor repo? > > > > > > sure, how can it be not? > > > oh! > > > I understand the confusion... > > > ovirt-engine-extensions-api-impl provides ovirt-engine-extensions-api :) > > > it is there... > > > > I don't see that package for fc21[1], maybe it's not being generated on > > ovirt-engine side? > > hmmm... sandro... do we build engine for fc21? if not probably the extensions > should not as well... right? > > > > > [1] - http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc21/ > > > > > > > > > > > > > > > > > > > > The job is already using ovirt-master-snapshot repo for the rpm > > > > > > build > > > > > > (the src-rpm build is not, that's why I ask where is it needed) > > > > > > > > > > not sure what src-rpm is in this context :( > > > > > > > > > > > > The job is subdivided in two main sections, creating the src.rpm and > > > > creating the rpm from it. For the first one is not using mock at all, > > > > so it's using the deps installed directly in the host it runs on, for > > > > the second, it's using mock, so it's installing all the deps needed by > > > > the src.rpm (and maybe more from the job config) inside the mock > > > > chroot, using the above repo. > > > > > > I am unsure why to create src rpm any dependency is required... it should > > > take spec as-is, no? > > > > Some projects like vdsm need some extra dependencies to be able to > > generate the spec file. I'd be glad if that was not required (only > > autotools at least). > > it is not... :) > also in vdsm the autotools should be required at build, not to package, this > is very strange. > the srpm is just archive of spec, tarball and patches. The problem is that the spec on vdsm is a template, and it's generated with autotools so you need at least autoools to get it, but also it pulls extra deps in to run make dist (not sure they are actually all needed though) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > [1] > > > > > > > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-fc21-x86_64_merged/9/artifact/exported-artifacts/root.log > > > > > > > ___ > > > > > > > Infra mailing list > > > > > > > Infra@ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > > > > > > -- > > > > > > David Caro > > > > > > > > > > > > Red Hat S.L. > > > > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > > > > > > > Tel.: +420 532 294 605 > > > > > > Email: dc...@redhat.com > > > > > > Web: www.redhat.com > > > > > > RHT Global #: 82-62605 > > > > > > > > > > > > > > -- > > > > David Caro > > > > > > > > Red Hat S.L. > > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > > > Tel.: +420 532 294 605 > > > > Email: dc...@redhat.com > > > > Web: www.redhat.com > > > > RHT Global #: 82-62605 > > > > > > > > -- > > David Caro > > > > Red Hat S.L. > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > Tel.: +420 532 294 605 > > Email: dc...@redhat.com > > Web: www.redhat.com > > RHT Global #: 82-62605 > > -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 pgpQShjAYca48.pgp Description: PGP signature ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api
- Original Message - > From: "David Caro" > To: "Alon Bar-Lev" > Cc: "infra" > Sent: Tuesday, December 9, 2014 4:47:42 PM > Subject: Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api > > On 12/09, Alon Bar-Lev wrote: > > > > > > - Original Message - > > > From: "David Caro" > > > To: "Alon Bar-Lev" > > > Cc: "infra" > > > Sent: Tuesday, December 9, 2014 4:38:43 PM > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > ovirt-engine-extensions-api > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > > > > - Original Message - > > > > > From: "David Caro" > > > > > To: "Alon Bar-Lev" > > > > > Cc: "infra" > > > > > Sent: Tuesday, December 9, 2014 4:31:59 PM > > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > > ovirt-engine-extensions-api > > > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > Hi, > > > > > > > > > > > > DEBUG util.py:366: Error: No Package found for > > > > > > ovirt-engine-extensions-api > > > > > > > > > > Where is that package and when is it needed? > > > > > > > > this package is produced (subpackage) of ovirt-engine rpm. > > > > it is needed to build all extensions. > > > > > > So should it be in ovirt-master-snapshor repo? > > > > sure, how can it be not? > > oh! > > I understand the confusion... > > ovirt-engine-extensions-api-impl provides ovirt-engine-extensions-api :) > > it is there... > > I don't see that package for fc21[1], maybe it's not being generated on > ovirt-engine side? hmmm... sandro... do we build engine for fc21? if not probably the extensions should not as well... right? > > [1] - http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc21/ > > > > > > > > > > > > > > > The job is already using ovirt-master-snapshot repo for the rpm build > > > > > (the src-rpm build is not, that's why I ask where is it needed) > > > > > > > > not sure what src-rpm is in this context :( > > > > > > > > > The job is subdivided in two main sections, creating the src.rpm and > > > creating the rpm from it. For the first one is not using mock at all, > > > so it's using the deps installed directly in the host it runs on, for > > > the second, it's using mock, so it's installing all the deps needed by > > > the src.rpm (and maybe more from the job config) inside the mock > > > chroot, using the above repo. > > > > I am unsure why to create src rpm any dependency is required... it should > > take spec as-is, no? > > Some projects like vdsm need some extra dependencies to be able to > generate the spec file. I'd be glad if that was not required (only > autotools at least). it is not... :) also in vdsm the autotools should be required at build, not to package, this is very strange. the srpm is just archive of spec, tarball and patches. > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > [1] > > > > > > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-fc21-x86_64_merged/9/artifact/exported-artifacts/root.log > > > > > > ___ > > > > > > Infra mailing list > > > > > > Infra@ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > > > > -- > > > > > David Caro > > > > > > > > > > Red Hat S.L. > > > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > > > > > Tel.: +420 532 294 605 > > > > > Email: dc...@redhat.com > > > > > Web: www.redhat.com > > > > > RHT Global #: 82-62605 > > > > > > > > > > > -- > > > David Caro > > > > > > Red Hat S.L. > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > Tel.: +420 532 294 605 > > > Email: dc...@redhat.com > > > Web: www.redhat.com > > > RHT Global #: 82-62605 > > > > > -- > David Caro > > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > Tel.: +420 532 294 605 > Email: dc...@redhat.com > Web: www.redhat.com > RHT Global #: 82-62605 > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api
On 12/09, Alon Bar-Lev wrote: > > > - Original Message - > > From: "David Caro" > > To: "Alon Bar-Lev" > > Cc: "infra" > > Sent: Tuesday, December 9, 2014 4:38:43 PM > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > ovirt-engine-extensions-api > > > > On 12/09, Alon Bar-Lev wrote: > > > > > > > > > - Original Message - > > > > From: "David Caro" > > > > To: "Alon Bar-Lev" > > > > Cc: "infra" > > > > Sent: Tuesday, December 9, 2014 4:31:59 PM > > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > > ovirt-engine-extensions-api > > > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > > Hi, > > > > > > > > > > DEBUG util.py:366: Error: No Package found for > > > > > ovirt-engine-extensions-api > > > > > > > > Where is that package and when is it needed? > > > > > > this package is produced (subpackage) of ovirt-engine rpm. > > > it is needed to build all extensions. > > > > So should it be in ovirt-master-snapshor repo? > > sure, how can it be not? > oh! > I understand the confusion... > ovirt-engine-extensions-api-impl provides ovirt-engine-extensions-api :) > it is there... I don't see that package for fc21[1], maybe it's not being generated on ovirt-engine side? [1] - http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc21/ > > > > > > > > > > The job is already using ovirt-master-snapshot repo for the rpm build > > > > (the src-rpm build is not, that's why I ask where is it needed) > > > > > > not sure what src-rpm is in this context :( > > > > > > The job is subdivided in two main sections, creating the src.rpm and > > creating the rpm from it. For the first one is not using mock at all, > > so it's using the deps installed directly in the host it runs on, for > > the second, it's using mock, so it's installing all the deps needed by > > the src.rpm (and maybe more from the job config) inside the mock > > chroot, using the above repo. > > I am unsure why to create src rpm any dependency is required... it should > take spec as-is, no? Some projects like vdsm need some extra dependencies to be able to generate the spec file. I'd be glad if that was not required (only autotools at least). > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > [1] > > > > > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-fc21-x86_64_merged/9/artifact/exported-artifacts/root.log > > > > > ___ > > > > > Infra mailing list > > > > > Infra@ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > > -- > > > > David Caro > > > > > > > > Red Hat S.L. > > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > > > Tel.: +420 532 294 605 > > > > Email: dc...@redhat.com > > > > Web: www.redhat.com > > > > RHT Global #: 82-62605 > > > > > > > > -- > > David Caro > > > > Red Hat S.L. > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > Tel.: +420 532 294 605 > > Email: dc...@redhat.com > > Web: www.redhat.com > > RHT Global #: 82-62605 > > -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 pgpxxJbuQR4As.pgp Description: PGP signature ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api
- Original Message - > From: "David Caro" > To: "Alon Bar-Lev" > Cc: "infra" > Sent: Tuesday, December 9, 2014 4:38:43 PM > Subject: Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api > > On 12/09, Alon Bar-Lev wrote: > > > > > > - Original Message - > > > From: "David Caro" > > > To: "Alon Bar-Lev" > > > Cc: "infra" > > > Sent: Tuesday, December 9, 2014 4:31:59 PM > > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > > ovirt-engine-extensions-api > > > > > > On 12/09, Alon Bar-Lev wrote: > > > > Hi, > > > > > > > > DEBUG util.py:366: Error: No Package found for > > > > ovirt-engine-extensions-api > > > > > > Where is that package and when is it needed? > > > > this package is produced (subpackage) of ovirt-engine rpm. > > it is needed to build all extensions. > > So should it be in ovirt-master-snapshor repo? sure, how can it be not? oh! I understand the confusion... ovirt-engine-extensions-api-impl provides ovirt-engine-extensions-api :) it is there... > > > > > > The job is already using ovirt-master-snapshot repo for the rpm build > > > (the src-rpm build is not, that's why I ask where is it needed) > > > > not sure what src-rpm is in this context :( > > > The job is subdivided in two main sections, creating the src.rpm and > creating the rpm from it. For the first one is not using mock at all, > so it's using the deps installed directly in the host it runs on, for > the second, it's using mock, so it's installing all the deps needed by > the src.rpm (and maybe more from the job config) inside the mock > chroot, using the above repo. I am unsure why to create src rpm any dependency is required... it should take spec as-is, no? > > > > > > > > > > > > > > Thanks, > > > > > > > > [1] > > > > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-fc21-x86_64_merged/9/artifact/exported-artifacts/root.log > > > > ___ > > > > Infra mailing list > > > > Infra@ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > -- > > > David Caro > > > > > > Red Hat S.L. > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > Tel.: +420 532 294 605 > > > Email: dc...@redhat.com > > > Web: www.redhat.com > > > RHT Global #: 82-62605 > > > > > -- > David Caro > > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > Tel.: +420 532 294 605 > Email: dc...@redhat.com > Web: www.redhat.com > RHT Global #: 82-62605 > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api
On 12/09, Alon Bar-Lev wrote: > > > - Original Message - > > From: "David Caro" > > To: "Alon Bar-Lev" > > Cc: "infra" > > Sent: Tuesday, December 9, 2014 4:31:59 PM > > Subject: Re: fc21-vm06.phx.ovirt.org slave missing > > ovirt-engine-extensions-api > > > > On 12/09, Alon Bar-Lev wrote: > > > Hi, > > > > > > DEBUG util.py:366: Error: No Package found for > > > ovirt-engine-extensions-api > > > > Where is that package and when is it needed? > > this package is produced (subpackage) of ovirt-engine rpm. > it is needed to build all extensions. So should it be in ovirt-master-snapshor repo? > > > The job is already using ovirt-master-snapshot repo for the rpm build > > (the src-rpm build is not, that's why I ask where is it needed) > > not sure what src-rpm is in this context :( The job is subdivided in two main sections, creating the src.rpm and creating the rpm from it. For the first one is not using mock at all, so it's using the deps installed directly in the host it runs on, for the second, it's using mock, so it's installing all the deps needed by the src.rpm (and maybe more from the job config) inside the mock chroot, using the above repo. > > > > > > > > > Thanks, > > > > > > [1] > > > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-fc21-x86_64_merged/9/artifact/exported-artifacts/root.log > > > ___ > > > Infra mailing list > > > Infra@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > -- > > David Caro > > > > Red Hat S.L. > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > Tel.: +420 532 294 605 > > Email: dc...@redhat.com > > Web: www.redhat.com > > RHT Global #: 82-62605 > > -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 pgpROEkYZHvTh.pgp Description: PGP signature ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Requests
Il 09/12/2014 15:32, Lev Veyde ha scritto: > Hi, > > 1) > I think that we should remove the older oVirt WGT RPM from the repo for all > distros. > > i.e. > http://resources.ovirt.org/pub/ovirt-3.5/rpm/el7/noarch/ovirt-guest-tools-3.5.0-0.5.master.noarch.rpm > > The oVirt WGT RPM is currently named ovirt-guest-tools-iso, i.e. > > http://resources.ovirt.org/pub/ovirt-3.5/rpm/el7/noarch/ovirt-guest-tools-iso-3.5-7.noarch.rpm > > So I think there is no reason to keep an older version in the repo. > I guess we'll need also a change in the spec file for ovirt-guest-tools-iso, something like: Obsoletes: ovirt-guest-tools for allowing people who already have ovirt-guest-tools to automatically receive the upgrade. I think we shouldn't remove an officially released rpm. > > 2) > We need to a symlink for oVirt WGT, so we could refer to the latest version > of the package in i.e. wiki pages. +1 > > Thanks in advance, > Lev Veyde. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api
- Original Message - > From: "David Caro" > To: "Alon Bar-Lev" > Cc: "infra" > Sent: Tuesday, December 9, 2014 4:31:59 PM > Subject: Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api > > On 12/09, Alon Bar-Lev wrote: > > Hi, > > > > DEBUG util.py:366: Error: No Package found for ovirt-engine-extensions-api > > Where is that package and when is it needed? this package is produced (subpackage) of ovirt-engine rpm. it is needed to build all extensions. > The job is already using ovirt-master-snapshot repo for the rpm build > (the src-rpm build is not, that's why I ask where is it needed) not sure what src-rpm is in this context :( > > > > > Thanks, > > > > [1] > > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-fc21-x86_64_merged/9/artifact/exported-artifacts/root.log > > ___ > > Infra mailing list > > Infra@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > -- > David Caro > > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > Tel.: +420 532 294 605 > Email: dc...@redhat.com > Web: www.redhat.com > RHT Global #: 82-62605 > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
[oVirt Jenkins] ovirt-engine_3.5_find-bugs_merged - Build # 1100 - Still Failing!
Project: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/ Build: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/1100/ Build Number: 1100 Build Status: Still Failing Triggered By: Triggered by Gerrit: http://gerrit.ovirt.org/36020 - Changes Since Last Success: - Changes for Build #1099 [Alon Bar-Lev] tools: tests: FirstMatchSimpleFilter ignore ordering Changes for Build #1100 [Liron Aravot] core: prevent disks from remaining in locked status - Failed Tests: - No tests ran. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Requests
Hi, 1) I think that we should remove the older oVirt WGT RPM from the repo for all distros. i.e. http://resources.ovirt.org/pub/ovirt-3.5/rpm/el7/noarch/ovirt-guest-tools-3.5.0-0.5.master.noarch.rpm The oVirt WGT RPM is currently named ovirt-guest-tools-iso, i.e. http://resources.ovirt.org/pub/ovirt-3.5/rpm/el7/noarch/ovirt-guest-tools-iso-3.5-7.noarch.rpm So I think there is no reason to keep an older version in the repo. 2) We need to a symlink for oVirt WGT, so we could refer to the latest version of the package in i.e. wiki pages. Thanks in advance, Lev Veyde. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api
On 12/09, Alon Bar-Lev wrote: > Hi, > > DEBUG util.py:366: Error: No Package found for ovirt-engine-extensions-api Where is that package and when is it needed? The job is already using ovirt-master-snapshot repo for the rpm build (the src-rpm build is not, that's why I ask where is it needed) > > Thanks, > > [1] > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-fc21-x86_64_merged/9/artifact/exported-artifacts/root.log > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 pgpsMbpJEmuLp.pgp Description: PGP signature ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
fc21-vm06.phx.ovirt.org slave missing ovirt-engine-extensions-api
Hi, DEBUG util.py:366: Error: No Package found for ovirt-engine-extensions-api Thanks, [1] http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-fc21-x86_64_merged/9/artifact/exported-artifacts/root.log ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: requerst for access for all vdsm jobs configuration
On 12/09, Ido Barkan wrote: > > > - Original Message - > From: "Ido Barkan" > To: infra@ovirt.org > Sent: Tuesday, November 25, 2014 3:36:12 PM > Subject: Re: requerst for access for all vdsm jobs configuration > > > > - Original Message - > > From: "Ido Barkan" > To: infra@ovirt.org > Sent: Wednesday, November 19, 2014 10:17:54 AM > Subject: requerst for access for all vdsm jobs configuration > > Hi infra, > > I would like to be granted access for all vdsm Jenkins jobs so I can help > fix/ change them. I am a new developer in the vdsm/network team. Hi Ido, We are moving all the tests to yaml format, you can fins some here: http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=refs/heads/master Feel free to send any patches to that repo with new jobs or fixes. If you need access to any other jobs not yet there, send the list and I'll add you manually, but we are trying to migrate as much as possible to yaml so give priority to yaml when creating/fixing them. Thanks! > > Thanks, > Ido > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 pgpBA6ow16YAN.pgp Description: PGP signature ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: requerst for access for all vdsm jobs configuration
- Original Message - From: "Ido Barkan" To: infra@ovirt.org Sent: Tuesday, November 25, 2014 3:36:12 PM Subject: Re: requerst for access for all vdsm jobs configuration - Original Message - From: "Ido Barkan" To: infra@ovirt.org Sent: Wednesday, November 19, 2014 10:17:54 AM Subject: requerst for access for all vdsm jobs configuration Hi infra, I would like to be granted access for all vdsm Jenkins jobs so I can help fix/ change them. I am a new developer in the vdsm/network team. Thanks, Ido ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
[oVirt Jenkins] ovirt-engine_3.5_find-bugs_merged - Build # 1099 - Failure!
Project: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/ Build: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/1099/ Build Number: 1099 Build Status: Failure Triggered By: Triggered by Gerrit: http://gerrit.ovirt.org/36007 - Changes Since Last Success: - Changes for Build #1099 [Alon Bar-Lev] tools: tests: FirstMatchSimpleFilter ignore ordering - Failed Tests: - No tests ran. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - > From: "David Caro" > To: "Yaniv Dary" > Cc: "Oved Ourfali" , de...@ovirt.org, infra@ovirt.org > Sent: Tuesday, December 9, 2014 2:40:43 PM > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > On 12/09, Yaniv Dary wrote: > > > > > > - Original Message - > > > From: "Oved Ourfali" > > > To: "David Caro" > > > Cc: infra@ovirt.org, de...@ovirt.org > > > Sent: Tuesday, December 9, 2014 2:27:14 PM > > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > > > top posting: > > > How about the following flow: > > > 1. You push a patch to gerrit. > > > 2. You need +1 on Testing in order to merge it. > > > 3. You have +1/-1 on the Tests if finished successfully/failed > > > 4. You find out you need to rebase. > > > 5. The rebase copies the result of the Tests of the previous patch-set... > > > if > > > it was +1, it remains +1 and you can merge (assuming you have +2 on CR). > > > If > > > it was -1 then you need to wait for the CI to finish, and it might set it > > > to > > > +1. > > > > > > Does that make sense? > > > > Yes, but only if you used rebase button and automatic rebase worked. > > In case of merge conflict you will need to wait after rebase for tests. > > Well, that's more or less what's happening today, we did set up the > flag propagation on trivial rebase time ago. I'll have to check how to > make jenkins ignore those trivial rebases only if they have a +1. > > So are you sure that having no merge conflict means that the rebase > patch works as before? (I imagine for example that you could have two > features that together might not work well, even if they do not touch > the same code) > > You minimize the probability that something will get wrong. It isn't 100%. Using Zuul is the right way to go, but until you have that I think what I proposed will make it both easy to use and maintain, and both safe up to 95% or so. > > > > > > > > > - Original Message - > > > > From: "Oved Ourfali" > > > > To: "David Caro" > > > > Cc: de...@ovirt.org, infra@ovirt.org > > > > Sent: Tuesday, December 9, 2014 1:13:57 PM > > > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > > > > > > > > > > > > > - Original Message - > > > > > From: "David Caro" > > > > > To: "Oved Ourfali" > > > > > Cc: infra@ovirt.org, de...@ovirt.org > > > > > Sent: Tuesday, December 9, 2014 12:12:19 PM > > > > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > > > > > > > On 12/09, Oved Ourfali wrote: > > > > > > What happens when rebasing? > > > > > > We can't afford waiting for tests to run on each rebase... as we > > > > > > might > > > > > > end > > > > > > up rebasing forever. > > > > > > > > > > For now we will have to, all the code that is going to be merged must > > > > > be tested as it is going to be merged, that means running the tests > > > > > in > > > > > the last rebase too. > > > > > > > > > > In the future there are plans on using a gating system like zuul, so > > > > > zuul will be the one monitoring the tests and merging when passes, so > > > > > you will just add the flag, and that will trigger the gate, that runs > > > > > the tests and merged the patch. > > > > > > > > > > It's unlikely that you'll have to wait forever, but there's nothing > > > > > avoiding you doing that (right now even). > > > > > > > > > > I'd like to put emphasis again on differentiating between tests that > > > > > are fast, that should run on each patch and tests that are slow, that > > > > > should run on each merge. That will improve the feedback times. > > > > > > > > > > > > > So let's apply that in the future. > > > > For now the amount of merges done is enormous, and it will be > > > > impossible to > > > > get things merged on a reasonable time. > > > > Again, I'm not against testing, but it should be done the right way... > > > > > > > > > > > > > > > > - Original Message - > > > > > > > From: "David Caro" > > > > > > > To: de...@ovirt.org, infra@ovirt.org > > > > > > > Sent: Tuesday, December 9, 2014 11:43:04 AM > > > > > > > Subject: [ovirt-devel] Creating a new gerrit flag > > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > e have been having an issue with gerrit patches being merged > > > > > > > before > > > > > > > jenkins ran any tests on them, to avoid it from happening again I > > > > > > > propose creating a new gerrit flag (Tests) with the following > > > > > > > specifics: > > > > > > > > > > > > > > > > > > > > > +1 - Tests passed/overrided > > > > > > > 0 - Tests pending > > > > > > > -1 - Tests broken > > > > > > > > > > > > > > where +1 is required to submit, +1 is set by jenkins when > > > > > > > passing the tests and -1 is set by jenkins in case it breaks any > > > > > > > tests. The +1 flag can be set also by maintainers to allow > > > > > > > overriding > > > > > > > the process. > > > > > > > > > > > > > > That way all the tests will be blocked until someone (hop
Re: [ovirt-devel] Creating a new gerrit flag
On 12/09, Yaniv Dary wrote: > > > - Original Message - > > From: "Oved Ourfali" > > To: "David Caro" > > Cc: infra@ovirt.org, de...@ovirt.org > > Sent: Tuesday, December 9, 2014 2:27:14 PM > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > top posting: > > How about the following flow: > > 1. You push a patch to gerrit. > > 2. You need +1 on Testing in order to merge it. > > 3. You have +1/-1 on the Tests if finished successfully/failed > > 4. You find out you need to rebase. > > 5. The rebase copies the result of the Tests of the previous patch-set... if > > it was +1, it remains +1 and you can merge (assuming you have +2 on CR). If > > it was -1 then you need to wait for the CI to finish, and it might set it to > > +1. > > > > Does that make sense? > > Yes, but only if you used rebase button and automatic rebase worked. > In case of merge conflict you will need to wait after rebase for tests. Well, that's more or less what's happening today, we did set up the flag propagation on trivial rebase time ago. I'll have to check how to make jenkins ignore those trivial rebases only if they have a +1. So are you sure that having no merge conflict means that the rebase patch works as before? (I imagine for example that you could have two features that together might not work well, even if they do not touch the same code) > > > > > - Original Message - > > > From: "Oved Ourfali" > > > To: "David Caro" > > > Cc: de...@ovirt.org, infra@ovirt.org > > > Sent: Tuesday, December 9, 2014 1:13:57 PM > > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > > > > > > > > > - Original Message - > > > > From: "David Caro" > > > > To: "Oved Ourfali" > > > > Cc: infra@ovirt.org, de...@ovirt.org > > > > Sent: Tuesday, December 9, 2014 12:12:19 PM > > > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > > > > > On 12/09, Oved Ourfali wrote: > > > > > What happens when rebasing? > > > > > We can't afford waiting for tests to run on each rebase... as we might > > > > > end > > > > > up rebasing forever. > > > > > > > > For now we will have to, all the code that is going to be merged must > > > > be tested as it is going to be merged, that means running the tests in > > > > the last rebase too. > > > > > > > > In the future there are plans on using a gating system like zuul, so > > > > zuul will be the one monitoring the tests and merging when passes, so > > > > you will just add the flag, and that will trigger the gate, that runs > > > > the tests and merged the patch. > > > > > > > > It's unlikely that you'll have to wait forever, but there's nothing > > > > avoiding you doing that (right now even). > > > > > > > > I'd like to put emphasis again on differentiating between tests that > > > > are fast, that should run on each patch and tests that are slow, that > > > > should run on each merge. That will improve the feedback times. > > > > > > > > > > So let's apply that in the future. > > > For now the amount of merges done is enormous, and it will be impossible > > > to > > > get things merged on a reasonable time. > > > Again, I'm not against testing, but it should be done the right way... > > > > > > > > > > > > > - Original Message - > > > > > > From: "David Caro" > > > > > > To: de...@ovirt.org, infra@ovirt.org > > > > > > Sent: Tuesday, December 9, 2014 11:43:04 AM > > > > > > Subject: [ovirt-devel] Creating a new gerrit flag > > > > > > > > > > > > Hi! > > > > > > > > > > > > e have been having an issue with gerrit patches being merged before > > > > > > jenkins ran any tests on them, to avoid it from happening again I > > > > > > propose creating a new gerrit flag (Tests) with the following > > > > > > specifics: > > > > > > > > > > > > > > > > > > +1 - Tests passed/overrided > > > > > > 0 - Tests pending > > > > > > -1 - Tests broken > > > > > > > > > > > > where +1 is required to submit, +1 is set by jenkins when > > > > > > passing the tests and -1 is set by jenkins in case it breaks any > > > > > > tests. The +1 flag can be set also by maintainers to allow > > > > > > overriding > > > > > > the process. > > > > > > > > > > > > That way all the tests will be blocked until someone (hopefully > > > > > > jenkins) adds the +1 flag, but if the maintainer wants to override > > > > > > the > > > > > > value, she just has to set that flag herself. > > > > > > > > > > > > > > > > > > What do you think? > > > > > > > > > > > > > > > > > > -- > > > > > > David Caro > > > > > > > > > > > > Red Hat S.L. > > > > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > > > > > > > Tel.: +420 532 294 605 > > > > > > Email: dc...@redhat.com > > > > > > Web: www.redhat.com > > > > > > RHT Global #: 82-62605 > > > > > > > > > > > > ___ > > > > > > Devel mailing list > > > > > > de...@ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/devel > > > >
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - > From: "Yaniv Dary" > To: "Oved Ourfali" > Cc: de...@ovirt.org, infra@ovirt.org > Sent: Tuesday, December 9, 2014 2:29:38 PM > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > - Original Message - > > From: "Oved Ourfali" > > To: "David Caro" > > Cc: infra@ovirt.org, de...@ovirt.org > > Sent: Tuesday, December 9, 2014 2:27:14 PM > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > top posting: > > How about the following flow: > > 1. You push a patch to gerrit. > > 2. You need +1 on Testing in order to merge it. > > 3. You have +1/-1 on the Tests if finished successfully/failed > > 4. You find out you need to rebase. > > 5. The rebase copies the result of the Tests of the previous patch-set... > > if > > it was +1, it remains +1 and you can merge (assuming you have +2 on CR). If > > it was -1 then you need to wait for the CI to finish, and it might set it > > to > > +1. > > > > Does that make sense? > > Yes, but only if you used rebase button and automatic rebase worked. > In case of merge conflict you will need to wait after rebase for tests. > In such cases I think the reviewer should compare and decide, rather than wait for tests to finish. > > > > - Original Message - > > > From: "Oved Ourfali" > > > To: "David Caro" > > > Cc: de...@ovirt.org, infra@ovirt.org > > > Sent: Tuesday, December 9, 2014 1:13:57 PM > > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > > > > > > > > > - Original Message - > > > > From: "David Caro" > > > > To: "Oved Ourfali" > > > > Cc: infra@ovirt.org, de...@ovirt.org > > > > Sent: Tuesday, December 9, 2014 12:12:19 PM > > > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > > > > > On 12/09, Oved Ourfali wrote: > > > > > What happens when rebasing? > > > > > We can't afford waiting for tests to run on each rebase... as we > > > > > might > > > > > end > > > > > up rebasing forever. > > > > > > > > For now we will have to, all the code that is going to be merged must > > > > be tested as it is going to be merged, that means running the tests in > > > > the last rebase too. > > > > > > > > In the future there are plans on using a gating system like zuul, so > > > > zuul will be the one monitoring the tests and merging when passes, so > > > > you will just add the flag, and that will trigger the gate, that runs > > > > the tests and merged the patch. > > > > > > > > It's unlikely that you'll have to wait forever, but there's nothing > > > > avoiding you doing that (right now even). > > > > > > > > I'd like to put emphasis again on differentiating between tests that > > > > are fast, that should run on each patch and tests that are slow, that > > > > should run on each merge. That will improve the feedback times. > > > > > > > > > > So let's apply that in the future. > > > For now the amount of merges done is enormous, and it will be impossible > > > to > > > get things merged on a reasonable time. > > > Again, I'm not against testing, but it should be done the right way... > > > > > > > > > > > > > - Original Message - > > > > > > From: "David Caro" > > > > > > To: de...@ovirt.org, infra@ovirt.org > > > > > > Sent: Tuesday, December 9, 2014 11:43:04 AM > > > > > > Subject: [ovirt-devel] Creating a new gerrit flag > > > > > > > > > > > > Hi! > > > > > > > > > > > > e have been having an issue with gerrit patches being merged before > > > > > > jenkins ran any tests on them, to avoid it from happening again I > > > > > > propose creating a new gerrit flag (Tests) with the following > > > > > > specifics: > > > > > > > > > > > > > > > > > > +1 - Tests passed/overrided > > > > > > 0 - Tests pending > > > > > > -1 - Tests broken > > > > > > > > > > > > where +1 is required to submit, +1 is set by jenkins when > > > > > > passing the tests and -1 is set by jenkins in case it breaks any > > > > > > tests. The +1 flag can be set also by maintainers to allow > > > > > > overriding > > > > > > the process. > > > > > > > > > > > > That way all the tests will be blocked until someone (hopefully > > > > > > jenkins) adds the +1 flag, but if the maintainer wants to override > > > > > > the > > > > > > value, she just has to set that flag herself. > > > > > > > > > > > > > > > > > > What do you think? > > > > > > > > > > > > > > > > > > -- > > > > > > David Caro > > > > > > > > > > > > Red Hat S.L. > > > > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > > > > > > > Tel.: +420 532 294 605 > > > > > > Email: dc...@redhat.com > > > > > > Web: www.redhat.com > > > > > > RHT Global #: 82-62605 > > > > > > > > > > > > ___ > > > > > > Devel mailing list > > > > > > de...@ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > > > > -- > > > > David Caro > > > > > > > > Red Hat S.L. > > > > Continuous Integration Engineer - EMEA ENG Virtualizati
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - > From: "Oved Ourfali" > To: "David Caro" > Cc: infra@ovirt.org, de...@ovirt.org > Sent: Tuesday, December 9, 2014 2:27:14 PM > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > top posting: > How about the following flow: > 1. You push a patch to gerrit. > 2. You need +1 on Testing in order to merge it. > 3. You have +1/-1 on the Tests if finished successfully/failed > 4. You find out you need to rebase. > 5. The rebase copies the result of the Tests of the previous patch-set... if > it was +1, it remains +1 and you can merge (assuming you have +2 on CR). If > it was -1 then you need to wait for the CI to finish, and it might set it to > +1. > > Does that make sense? Yes, but only if you used rebase button and automatic rebase worked. In case of merge conflict you will need to wait after rebase for tests. > > - Original Message - > > From: "Oved Ourfali" > > To: "David Caro" > > Cc: de...@ovirt.org, infra@ovirt.org > > Sent: Tuesday, December 9, 2014 1:13:57 PM > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > > > > > - Original Message - > > > From: "David Caro" > > > To: "Oved Ourfali" > > > Cc: infra@ovirt.org, de...@ovirt.org > > > Sent: Tuesday, December 9, 2014 12:12:19 PM > > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > > > On 12/09, Oved Ourfali wrote: > > > > What happens when rebasing? > > > > We can't afford waiting for tests to run on each rebase... as we might > > > > end > > > > up rebasing forever. > > > > > > For now we will have to, all the code that is going to be merged must > > > be tested as it is going to be merged, that means running the tests in > > > the last rebase too. > > > > > > In the future there are plans on using a gating system like zuul, so > > > zuul will be the one monitoring the tests and merging when passes, so > > > you will just add the flag, and that will trigger the gate, that runs > > > the tests and merged the patch. > > > > > > It's unlikely that you'll have to wait forever, but there's nothing > > > avoiding you doing that (right now even). > > > > > > I'd like to put emphasis again on differentiating between tests that > > > are fast, that should run on each patch and tests that are slow, that > > > should run on each merge. That will improve the feedback times. > > > > > > > So let's apply that in the future. > > For now the amount of merges done is enormous, and it will be impossible to > > get things merged on a reasonable time. > > Again, I'm not against testing, but it should be done the right way... > > > > > > > > > > - Original Message - > > > > > From: "David Caro" > > > > > To: de...@ovirt.org, infra@ovirt.org > > > > > Sent: Tuesday, December 9, 2014 11:43:04 AM > > > > > Subject: [ovirt-devel] Creating a new gerrit flag > > > > > > > > > > Hi! > > > > > > > > > > e have been having an issue with gerrit patches being merged before > > > > > jenkins ran any tests on them, to avoid it from happening again I > > > > > propose creating a new gerrit flag (Tests) with the following > > > > > specifics: > > > > > > > > > > > > > > > +1 - Tests passed/overrided > > > > > 0 - Tests pending > > > > > -1 - Tests broken > > > > > > > > > > where +1 is required to submit, +1 is set by jenkins when > > > > > passing the tests and -1 is set by jenkins in case it breaks any > > > > > tests. The +1 flag can be set also by maintainers to allow overriding > > > > > the process. > > > > > > > > > > That way all the tests will be blocked until someone (hopefully > > > > > jenkins) adds the +1 flag, but if the maintainer wants to override > > > > > the > > > > > value, she just has to set that flag herself. > > > > > > > > > > > > > > > What do you think? > > > > > > > > > > > > > > > -- > > > > > David Caro > > > > > > > > > > Red Hat S.L. > > > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > > > > > Tel.: +420 532 294 605 > > > > > Email: dc...@redhat.com > > > > > Web: www.redhat.com > > > > > RHT Global #: 82-62605 > > > > > > > > > > ___ > > > > > Devel mailing list > > > > > de...@ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > > -- > > > David Caro > > > > > > Red Hat S.L. > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > Tel.: +420 532 294 605 > > > Email: dc...@redhat.com > > > Web: www.redhat.com > > > RHT Global #: 82-62605 > > > > > > ___ > > > Devel mailing list > > > de...@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/devel > > ___ > > Devel mailing list > > de...@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > > > ___ > Devel mailing list > de...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___
Re: [ovirt-devel] Creating a new gerrit flag
top posting: How about the following flow: 1. You push a patch to gerrit. 2. You need +1 on Testing in order to merge it. 3. You have +1/-1 on the Tests if finished successfully/failed 4. You find out you need to rebase. 5. The rebase copies the result of the Tests of the previous patch-set... if it was +1, it remains +1 and you can merge (assuming you have +2 on CR). If it was -1 then you need to wait for the CI to finish, and it might set it to +1. Does that make sense? - Original Message - > From: "Oved Ourfali" > To: "David Caro" > Cc: de...@ovirt.org, infra@ovirt.org > Sent: Tuesday, December 9, 2014 1:13:57 PM > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > - Original Message - > > From: "David Caro" > > To: "Oved Ourfali" > > Cc: infra@ovirt.org, de...@ovirt.org > > Sent: Tuesday, December 9, 2014 12:12:19 PM > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > On 12/09, Oved Ourfali wrote: > > > What happens when rebasing? > > > We can't afford waiting for tests to run on each rebase... as we might > > > end > > > up rebasing forever. > > > > For now we will have to, all the code that is going to be merged must > > be tested as it is going to be merged, that means running the tests in > > the last rebase too. > > > > In the future there are plans on using a gating system like zuul, so > > zuul will be the one monitoring the tests and merging when passes, so > > you will just add the flag, and that will trigger the gate, that runs > > the tests and merged the patch. > > > > It's unlikely that you'll have to wait forever, but there's nothing > > avoiding you doing that (right now even). > > > > I'd like to put emphasis again on differentiating between tests that > > are fast, that should run on each patch and tests that are slow, that > > should run on each merge. That will improve the feedback times. > > > > So let's apply that in the future. > For now the amount of merges done is enormous, and it will be impossible to > get things merged on a reasonable time. > Again, I'm not against testing, but it should be done the right way... > > > > > > > - Original Message - > > > > From: "David Caro" > > > > To: de...@ovirt.org, infra@ovirt.org > > > > Sent: Tuesday, December 9, 2014 11:43:04 AM > > > > Subject: [ovirt-devel] Creating a new gerrit flag > > > > > > > > Hi! > > > > > > > > e have been having an issue with gerrit patches being merged before > > > > jenkins ran any tests on them, to avoid it from happening again I > > > > propose creating a new gerrit flag (Tests) with the following > > > > specifics: > > > > > > > > > > > > +1 - Tests passed/overrided > > > > 0 - Tests pending > > > > -1 - Tests broken > > > > > > > > where +1 is required to submit, +1 is set by jenkins when > > > > passing the tests and -1 is set by jenkins in case it breaks any > > > > tests. The +1 flag can be set also by maintainers to allow overriding > > > > the process. > > > > > > > > That way all the tests will be blocked until someone (hopefully > > > > jenkins) adds the +1 flag, but if the maintainer wants to override the > > > > value, she just has to set that flag herself. > > > > > > > > > > > > What do you think? > > > > > > > > > > > > -- > > > > David Caro > > > > > > > > Red Hat S.L. > > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > > > Tel.: +420 532 294 605 > > > > Email: dc...@redhat.com > > > > Web: www.redhat.com > > > > RHT Global #: 82-62605 > > > > > > > > ___ > > > > Devel mailing list > > > > de...@ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/devel > > > > -- > > David Caro > > > > Red Hat S.L. > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > Tel.: +420 532 294 605 > > Email: dc...@redhat.com > > Web: www.redhat.com > > RHT Global #: 82-62605 > > > > ___ > > Devel mailing list > > de...@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > ___ > Devel mailing list > de...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
[oVirt Jenkins] ovirt-engine_3.5_find-bugs_merged - Build # 1096 - Fixed!
Project: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/ Build: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/1096/ Build Number: 1096 Build Status: Fixed Triggered By: Triggered by Gerrit: http://gerrit.ovirt.org/35997 - Changes Since Last Success: - Changes for Build #1094 [Maor Lipchuk] core: Add a warnning when OVF_STORE disks does not exists. Changes for Build #1095 [Maor Lipchuk] core: Add a warnning when OVF_STORE disks does not exists. [Maor Lipchuk] core: Fetch unregisterd entity from all the Storage Domains. Changes for Build #1096 [Maor Lipchuk] core: Increment DB Generation when image is copied - Failed Tests: - No tests ran. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
[oVirt Jenkins] ovirt-engine_3.5_find-bugs_merged - Build # 1095 - Still Failing!
Project: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/ Build: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/1095/ Build Number: 1095 Build Status: Still Failing Triggered By: Triggered by Gerrit: http://gerrit.ovirt.org/35996 - Changes Since Last Success: - Changes for Build #1094 [Maor Lipchuk] core: Add a warnning when OVF_STORE disks does not exists. Changes for Build #1095 [Maor Lipchuk] core: Add a warnning when OVF_STORE disks does not exists. [Maor Lipchuk] core: Fetch unregisterd entity from all the Storage Domains. - Failed Tests: - No tests ran. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
[oVirt Jenkins] ovirt-engine_3.5_find-bugs_merged - Build # 1094 - Failure!
Project: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/ Build: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/1094/ Build Number: 1094 Build Status: Failure Triggered By: Triggered by Gerrit: http://gerrit.ovirt.org/35995 - Changes Since Last Success: - Changes for Build #1094 [Maor Lipchuk] core: Add a warnning when OVF_STORE disks does not exists. - Failed Tests: - No tests ran. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - > From: "David Caro" > To: "Oved Ourfali" > Cc: infra@ovirt.org, de...@ovirt.org > Sent: Tuesday, December 9, 2014 12:12:19 PM > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > On 12/09, Oved Ourfali wrote: > > What happens when rebasing? > > We can't afford waiting for tests to run on each rebase... as we might end > > up rebasing forever. > > For now we will have to, all the code that is going to be merged must > be tested as it is going to be merged, that means running the tests in > the last rebase too. > > In the future there are plans on using a gating system like zuul, so > zuul will be the one monitoring the tests and merging when passes, so > you will just add the flag, and that will trigger the gate, that runs > the tests and merged the patch. > > It's unlikely that you'll have to wait forever, but there's nothing > avoiding you doing that (right now even). > > I'd like to put emphasis again on differentiating between tests that > are fast, that should run on each patch and tests that are slow, that > should run on each merge. That will improve the feedback times. > So let's apply that in the future. For now the amount of merges done is enormous, and it will be impossible to get things merged on a reasonable time. Again, I'm not against testing, but it should be done the right way... > > > > - Original Message - > > > From: "David Caro" > > > To: de...@ovirt.org, infra@ovirt.org > > > Sent: Tuesday, December 9, 2014 11:43:04 AM > > > Subject: [ovirt-devel] Creating a new gerrit flag > > > > > > Hi! > > > > > > e have been having an issue with gerrit patches being merged before > > > jenkins ran any tests on them, to avoid it from happening again I > > > propose creating a new gerrit flag (Tests) with the following > > > specifics: > > > > > > > > > +1 - Tests passed/overrided > > > 0 - Tests pending > > > -1 - Tests broken > > > > > > where +1 is required to submit, +1 is set by jenkins when > > > passing the tests and -1 is set by jenkins in case it breaks any > > > tests. The +1 flag can be set also by maintainers to allow overriding > > > the process. > > > > > > That way all the tests will be blocked until someone (hopefully > > > jenkins) adds the +1 flag, but if the maintainer wants to override the > > > value, she just has to set that flag herself. > > > > > > > > > What do you think? > > > > > > > > > -- > > > David Caro > > > > > > Red Hat S.L. > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > Tel.: +420 532 294 605 > > > Email: dc...@redhat.com > > > Web: www.redhat.com > > > RHT Global #: 82-62605 > > > > > > ___ > > > Devel mailing list > > > de...@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/devel > > -- > David Caro > > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > Tel.: +420 532 294 605 > Email: dc...@redhat.com > Web: www.redhat.com > RHT Global #: 82-62605 > > ___ > Devel mailing list > de...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
[oVirt Jenkins] ovirt-engine_3.5_find-bugs_merged - Build # 1093 - Fixed!
Project: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/ Build: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/1093/ Build Number: 1093 Build Status: Fixed Triggered By: Triggered by Gerrit: http://gerrit.ovirt.org/36004 - Changes Since Last Success: - Changes for Build #1088 [Tomer Saban] webadmin: CPU shares custom value is now possible Changes for Build #1089 [Gilad Chaplik] webadmin: fix cpu profile changes for import Changes for Build #1090 [Vitor de Lima] core, engine: Disable CPU pinning validation Changes for Build #1091 [Maor Lipchuk] webadmin: Remove Storage connection on import domain failure Changes for Build #1092 [Allon Mureinik] webadmin: ImportVmFromExportDomainModel#doInit DLS Changes for Build #1093 [Yedidyah Bar David] packaging: rename: drop handling of RedirectServletReportsPage - Failed Tests: - No tests ran. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
[oVirt Jenkins] ovirt-engine_3.5_find-bugs_merged - Build # 1092 - Failure!
Project: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/ Build: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/1092/ Build Number: 1092 Build Status: Failure Triggered By: Triggered by Gerrit: http://gerrit.ovirt.org/36008 - Changes Since Last Success: - Changes for Build #1088 [Tomer Saban] webadmin: CPU shares custom value is now possible Changes for Build #1089 [Gilad Chaplik] webadmin: fix cpu profile changes for import Changes for Build #1090 [Vitor de Lima] core, engine: Disable CPU pinning validation Changes for Build #1091 [Maor Lipchuk] webadmin: Remove Storage connection on import domain failure Changes for Build #1092 [Allon Mureinik] webadmin: ImportVmFromExportDomainModel#doInit DLS - Failed Tests: - No tests ran. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - > From: "David Caro" > To: "Oved Ourfali" > Cc: infra@ovirt.org, de...@ovirt.org > Sent: Tuesday, December 9, 2014 12:12:19 PM > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > On 12/09, Oved Ourfali wrote: > > What happens when rebasing? > > We can't afford waiting for tests to run on each rebase... as we might end > > up rebasing forever. > > For now we will have to, all the code that is going to be merged must > be tested as it is going to be merged, that means running the tests in > the last rebase too. > > In the future there are plans on using a gating system like zuul, so > zuul will be the one monitoring the tests and merging when passes, so > you will just add the flag, and that will trigger the gate, that runs > the tests and merged the patch. > > It's unlikely that you'll have to wait forever, but there's nothing > avoiding you doing that (right now even). > > I'd like to put emphasis again on differentiating between tests that > are fast, that should run on each patch and tests that are slow, that > should run on each merge. That will improve the feedback times. +1 Tests are more critical than fast merges, the consequences of merging untest patches is worse. > > > > > - Original Message - > > > From: "David Caro" > > > To: de...@ovirt.org, infra@ovirt.org > > > Sent: Tuesday, December 9, 2014 11:43:04 AM > > > Subject: [ovirt-devel] Creating a new gerrit flag > > > > > > Hi! > > > > > > e have been having an issue with gerrit patches being merged before > > > jenkins ran any tests on them, to avoid it from happening again I > > > propose creating a new gerrit flag (Tests) with the following > > > specifics: > > > > > > > > > +1 - Tests passed/overrided > > > 0 - Tests pending > > > -1 - Tests broken > > > > > > where +1 is required to submit, +1 is set by jenkins when > > > passing the tests and -1 is set by jenkins in case it breaks any > > > tests. The +1 flag can be set also by maintainers to allow overriding > > > the process. > > > > > > That way all the tests will be blocked until someone (hopefully > > > jenkins) adds the +1 flag, but if the maintainer wants to override the > > > value, she just has to set that flag herself. > > > > > > > > > What do you think? > > > > > > > > > -- > > > David Caro > > > > > > Red Hat S.L. > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > Tel.: +420 532 294 605 > > > Email: dc...@redhat.com > > > Web: www.redhat.com > > > RHT Global #: 82-62605 > > > > > > ___ > > > Devel mailing list > > > de...@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/devel > > -- > David Caro > > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > Tel.: +420 532 294 605 > Email: dc...@redhat.com > Web: www.redhat.com > RHT Global #: 82-62605 > > ___ > Devel mailing list > de...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - > From: "Yaniv Dary" > To: "Oved Ourfali" > Cc: infra@ovirt.org, de...@ovirt.org > Sent: Tuesday, December 9, 2014 12:11:31 PM > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > - Original Message - > > From: "Yaniv Dary" > > To: "Oved Ourfali" > > Cc: de...@ovirt.org, infra@ovirt.org > > Sent: Tuesday, December 9, 2014 12:10:36 PM > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > > > > > - Original Message - > > > From: "Oved Ourfali" > > > To: "David Caro" > > > Cc: infra@ovirt.org, de...@ovirt.org > > > Sent: Tuesday, December 9, 2014 11:52:11 AM > > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > > > What happens when rebasing? > > > We can't afford waiting for tests to run on each rebase... as we might > > > end > > > up > > > rebasing forever. > > > > why can't you rerun tests after rebase to run tests if the patch is > > critical > > and pending? > > I meant manually. > You can run. The issue is that while running them, someone else can merge something, and then you'll need to rebase again... and again... and again... > > > > > > > > - Original Message - > > > > From: "David Caro" > > > > To: de...@ovirt.org, infra@ovirt.org > > > > Sent: Tuesday, December 9, 2014 11:43:04 AM > > > > Subject: [ovirt-devel] Creating a new gerrit flag > > > > > > > > Hi! > > > > > > > > e have been having an issue with gerrit patches being merged before > > > > jenkins ran any tests on them, to avoid it from happening again I > > > > propose creating a new gerrit flag (Tests) with the following > > > > specifics: > > > > > > > > > > > > +1 - Tests passed/overrided > > > > 0 - Tests pending > > > > -1 - Tests broken > > > > > > > > where +1 is required to submit, +1 is set by jenkins when > > > > passing the tests and -1 is set by jenkins in case it breaks any > > > > tests. The +1 flag can be set also by maintainers to allow overriding > > > > the process. > > > > > > > > That way all the tests will be blocked until someone (hopefully > > > > jenkins) adds the +1 flag, but if the maintainer wants to override the > > > > value, she just has to set that flag herself. > > > > > > > > > > > > What do you think? > > > > > > > > > > > > -- > > > > David Caro > > > > > > > > Red Hat S.L. > > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > > > Tel.: +420 532 294 605 > > > > Email: dc...@redhat.com > > > > Web: www.redhat.com > > > > RHT Global #: 82-62605 > > > > > > > > ___ > > > > Devel mailing list > > > > de...@ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/devel > > > ___ > > > Devel mailing list > > > de...@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > ___ > > Devel mailing list > > de...@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > > > ___ > 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
Re: [ovirt-devel] Creating a new gerrit flag
On 12/09, Oved Ourfali wrote: > What happens when rebasing? > We can't afford waiting for tests to run on each rebase... as we might end up > rebasing forever. For now we will have to, all the code that is going to be merged must be tested as it is going to be merged, that means running the tests in the last rebase too. In the future there are plans on using a gating system like zuul, so zuul will be the one monitoring the tests and merging when passes, so you will just add the flag, and that will trigger the gate, that runs the tests and merged the patch. It's unlikely that you'll have to wait forever, but there's nothing avoiding you doing that (right now even). I'd like to put emphasis again on differentiating between tests that are fast, that should run on each patch and tests that are slow, that should run on each merge. That will improve the feedback times. > > - Original Message - > > From: "David Caro" > > To: de...@ovirt.org, infra@ovirt.org > > Sent: Tuesday, December 9, 2014 11:43:04 AM > > Subject: [ovirt-devel] Creating a new gerrit flag > > > > Hi! > > > > e have been having an issue with gerrit patches being merged before > > jenkins ran any tests on them, to avoid it from happening again I > > propose creating a new gerrit flag (Tests) with the following > > specifics: > > > > > > +1 - Tests passed/overrided > > 0 - Tests pending > > -1 - Tests broken > > > > where +1 is required to submit, +1 is set by jenkins when > > passing the tests and -1 is set by jenkins in case it breaks any > > tests. The +1 flag can be set also by maintainers to allow overriding > > the process. > > > > That way all the tests will be blocked until someone (hopefully > > jenkins) adds the +1 flag, but if the maintainer wants to override the > > value, she just has to set that flag herself. > > > > > > What do you think? > > > > > > -- > > David Caro > > > > Red Hat S.L. > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > Tel.: +420 532 294 605 > > Email: dc...@redhat.com > > Web: www.redhat.com > > RHT Global #: 82-62605 > > > > ___ > > Devel mailing list > > de...@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 pgpRROsKclcom.pgp Description: PGP signature ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - > From: "Yaniv Dary" > To: "Oved Ourfali" > Cc: de...@ovirt.org, infra@ovirt.org > Sent: Tuesday, December 9, 2014 12:10:36 PM > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > - Original Message - > > From: "Oved Ourfali" > > To: "David Caro" > > Cc: infra@ovirt.org, de...@ovirt.org > > Sent: Tuesday, December 9, 2014 11:52:11 AM > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > What happens when rebasing? > > We can't afford waiting for tests to run on each rebase... as we might end > > up > > rebasing forever. > > why can't you rerun tests after rebase to run tests if the patch is critical > and pending? I meant manually. > > > > > - Original Message - > > > From: "David Caro" > > > To: de...@ovirt.org, infra@ovirt.org > > > Sent: Tuesday, December 9, 2014 11:43:04 AM > > > Subject: [ovirt-devel] Creating a new gerrit flag > > > > > > Hi! > > > > > > e have been having an issue with gerrit patches being merged before > > > jenkins ran any tests on them, to avoid it from happening again I > > > propose creating a new gerrit flag (Tests) with the following > > > specifics: > > > > > > > > > +1 - Tests passed/overrided > > > 0 - Tests pending > > > -1 - Tests broken > > > > > > where +1 is required to submit, +1 is set by jenkins when > > > passing the tests and -1 is set by jenkins in case it breaks any > > > tests. The +1 flag can be set also by maintainers to allow overriding > > > the process. > > > > > > That way all the tests will be blocked until someone (hopefully > > > jenkins) adds the +1 flag, but if the maintainer wants to override the > > > value, she just has to set that flag herself. > > > > > > > > > What do you think? > > > > > > > > > -- > > > David Caro > > > > > > Red Hat S.L. > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > Tel.: +420 532 294 605 > > > Email: dc...@redhat.com > > > Web: www.redhat.com > > > RHT Global #: 82-62605 > > > > > > ___ > > > Devel mailing list > > > de...@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/devel > > ___ > > Devel mailing list > > de...@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > > > ___ > Devel mailing list > de...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - > From: "Oved Ourfali" > To: "David Caro" > Cc: infra@ovirt.org, de...@ovirt.org > Sent: Tuesday, December 9, 2014 11:52:11 AM > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > What happens when rebasing? > We can't afford waiting for tests to run on each rebase... as we might end up > rebasing forever. why can't you rerun tests after rebase to run tests if the patch is critical and pending? > > - Original Message - > > From: "David Caro" > > To: de...@ovirt.org, infra@ovirt.org > > Sent: Tuesday, December 9, 2014 11:43:04 AM > > Subject: [ovirt-devel] Creating a new gerrit flag > > > > Hi! > > > > e have been having an issue with gerrit patches being merged before > > jenkins ran any tests on them, to avoid it from happening again I > > propose creating a new gerrit flag (Tests) with the following > > specifics: > > > > > > +1 - Tests passed/overrided > > 0 - Tests pending > > -1 - Tests broken > > > > where +1 is required to submit, +1 is set by jenkins when > > passing the tests and -1 is set by jenkins in case it breaks any > > tests. The +1 flag can be set also by maintainers to allow overriding > > the process. > > > > That way all the tests will be blocked until someone (hopefully > > jenkins) adds the +1 flag, but if the maintainer wants to override the > > value, she just has to set that flag herself. > > > > > > What do you think? > > > > > > -- > > David Caro > > > > Red Hat S.L. > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > Tel.: +420 532 294 605 > > Email: dc...@redhat.com > > Web: www.redhat.com > > RHT Global #: 82-62605 > > > > ___ > > Devel mailing list > > de...@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > ___ > Devel mailing list > de...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - > From: "Francesco Romani" > To: "David Caro" > Cc: infra@ovirt.org, de...@ovirt.org > Sent: Tuesday, December 9, 2014 11:48:00 AM > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > - Original Message - > > From: "David Caro" > > To: de...@ovirt.org, infra@ovirt.org > > Sent: Tuesday, December 9, 2014 10:43:04 AM > > Subject: [ovirt-devel] Creating a new gerrit flag > > > > Hi! > > > > e have been having an issue with gerrit patches being merged before > > jenkins ran any tests on them, to avoid it from happening again I > > propose creating a new gerrit flag (Tests) with the following > > specifics: > > > > > > +1 - Tests passed/overrided > > 0 - Tests pending > > -1 - Tests broken > > > > where +1 is required to submit, +1 is set by jenkins when > > passing the tests and -1 is set by jenkins in case it breaks any > > tests. The +1 flag can be set also by maintainers to allow overriding > > the process. > > > > That way all the tests will be blocked until someone (hopefully > > jenkins) adds the +1 flag, but if the maintainer wants to override the > > value, she just has to set that flag herself. > > > > > > What do you think? > > Looks good, but there is a scenario which worries me a bit. > > It happened in the past times that an otherwise good and working patch > failed the tests because, for example, pep8 or pyflakes became stricter > about the code formatting. > > Can the maintainer override such a -1 from failed tests in that case? > (probably yes, but worth asking) If a test fails on this, it will fail on all patches that will follow as well, so I don't think it's a bad requirement that you need to fix the underlying issues for patches to be merged. Without running tests you don't have any good wya to make sure a patch is 'good'. > > Thanks, > > -- > Francesco Romani > RedHat Engineering Virtualization R & D > Phone: 8261328 > IRC: fromani > ___ > Devel mailing list > de...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ovirt-devel] Creating a new gerrit flag
What happens when rebasing? We can't afford waiting for tests to run on each rebase... as we might end up rebasing forever. - Original Message - > From: "David Caro" > To: de...@ovirt.org, infra@ovirt.org > Sent: Tuesday, December 9, 2014 11:43:04 AM > Subject: [ovirt-devel] Creating a new gerrit flag > > Hi! > > e have been having an issue with gerrit patches being merged before > jenkins ran any tests on them, to avoid it from happening again I > propose creating a new gerrit flag (Tests) with the following > specifics: > > > +1 - Tests passed/overrided > 0 - Tests pending > -1 - Tests broken > > where +1 is required to submit, +1 is set by jenkins when > passing the tests and -1 is set by jenkins in case it breaks any > tests. The +1 flag can be set also by maintainers to allow overriding > the process. > > That way all the tests will be blocked until someone (hopefully > jenkins) adds the +1 flag, but if the maintainer wants to override the > value, she just has to set that flag herself. > > > What do you think? > > > -- > David Caro > > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > Tel.: +420 532 294 605 > Email: dc...@redhat.com > Web: www.redhat.com > RHT Global #: 82-62605 > > ___ > Devel mailing list > de...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - > From: "David Caro" > To: de...@ovirt.org, infra@ovirt.org > Sent: Tuesday, December 9, 2014 10:43:04 AM > Subject: [ovirt-devel] Creating a new gerrit flag > > Hi! > > e have been having an issue with gerrit patches being merged before > jenkins ran any tests on them, to avoid it from happening again I > propose creating a new gerrit flag (Tests) with the following > specifics: > > > +1 - Tests passed/overrided > 0 - Tests pending > -1 - Tests broken > > where +1 is required to submit, +1 is set by jenkins when > passing the tests and -1 is set by jenkins in case it breaks any > tests. The +1 flag can be set also by maintainers to allow overriding > the process. > > That way all the tests will be blocked until someone (hopefully > jenkins) adds the +1 flag, but if the maintainer wants to override the > value, she just has to set that flag herself. > > > What do you think? Looks good, but there is a scenario which worries me a bit. It happened in the past times that an otherwise good and working patch failed the tests because, for example, pep8 or pyflakes became stricter about the code formatting. Can the maintainer override such a -1 from failed tests in that case? (probably yes, but worth asking) Thanks, -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Creating a new gerrit flag
Hi! e have been having an issue with gerrit patches being merged before jenkins ran any tests on them, to avoid it from happening again I propose creating a new gerrit flag (Tests) with the following specifics: +1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow overriding the process. That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to override the value, she just has to set that flag herself. What do you think? -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 pgpnO1fZeFxA2.pgp Description: PGP signature ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: findbugs errors -- any way to prevent mad bot from rampant -1s?
- Original Message - > From: "David Caro" > To: "Greg Sheremeta" > Cc: "Eyal Edri" , de...@ovirt.org, infra@ovirt.org > Sent: Tuesday, December 9, 2014 11:09:27 AM > Subject: Re: findbugs errors -- any way to prevent mad bot from rampant -1s? > > On 12/08, Greg Sheremeta wrote: > > Hi, > > > > Is there any way to prevent this [1] from happening? > > > > Some patch got merged that findbugs complains about. Basically no > > patches can be merged until that is fixed and everybody rebases > > everything (because the bot -1's everything). That doesn't seem right. > > What is not right is merging a patch that breaks findbugs. > > How do you suggest avoiding that? Ignoring the findbugs result always? > Forcing to pass it always? (that is, not allowing maintainers to > remove the jenkins reviewer). > If we only test you code (check out instead of cherry-pick) then you > will not have that issue, but you'll have to test anyhow the > cherry-pick before merging and we have the same issue + a lot of tests > on old code that when rebasing become opsolete. > > You could try to cross compare jobs running on merged code with the > jobs runing on non-merged code and disable voting if merged code is > breaking, but you will not be able to merge anyhow as you must make > sure the tests pass before merging, so you need a stable repo. > > > So in summary, yes there's something we can do, fix the offeding patch > (or revert it) and force any patchset to pass the tests before > merging. > > totally agree. here's the offending patch that was merged both to master and to 3.5 stable branch: http://gerrit.ovirt.org/#/c/35931/ you can see clearly jenkins failed on it: Patch Set 3: Build Unstable http://jenkins.ovirt.org/job/ovirt-engine_master_unit-tests_gerrit/22350/ : SUCCESS http://jenkins.ovirt.org/job/ovirt-engine_master_find-bugs_gerrit/21862/ : The patch does not pass the findbugs http://jenkins.ovirt.org/job/ovirt_engine_master_compile_checkstyle_gerrit/38550/ : SUCCESS so please either revert it or fix it to unblock all other patches. e. > > > > [1] http://i.imgur.com/NNHx1bq.png > > > > -- > > Greg Sheremeta > > Red Hat, Inc. > > Sr. Software Engineer, RHEV > > Cell: 919-807-1086 > > gsher...@redhat.com > > ___ > > Infra mailing list > > Infra@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > -- > David Caro > > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > Tel.: +420 532 294 605 > Email: dc...@redhat.com > Web: www.redhat.com > RHT Global #: 82-62605 > > ___ > 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
Re: findbugs errors -- any way to prevent mad bot from rampant -1s?
On 12/08, Greg Sheremeta wrote: > Hi, > > Is there any way to prevent this [1] from happening? > > Some patch got merged that findbugs complains about. Basically no > patches can be merged until that is fixed and everybody rebases > everything (because the bot -1's everything). That doesn't seem right. What is not right is merging a patch that breaks findbugs. How do you suggest avoiding that? Ignoring the findbugs result always? Forcing to pass it always? (that is, not allowing maintainers to remove the jenkins reviewer). If we only test you code (check out instead of cherry-pick) then you will not have that issue, but you'll have to test anyhow the cherry-pick before merging and we have the same issue + a lot of tests on old code that when rebasing become opsolete. You could try to cross compare jobs running on merged code with the jobs runing on non-merged code and disable voting if merged code is breaking, but you will not be able to merge anyhow as you must make sure the tests pass before merging, so you need a stable repo. So in summary, yes there's something we can do, fix the offeding patch (or revert it) and force any patchset to pass the tests before merging. > > [1] http://i.imgur.com/NNHx1bq.png > > -- > Greg Sheremeta > Red Hat, Inc. > Sr. Software Engineer, RHEV > Cell: 919-807-1086 > gsher...@redhat.com > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 pgpQI5qYl1A69.pgp Description: PGP signature ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
[oVirt Jenkins] ovirt-engine_3.5_find-bugs_merged - Build # 1091 - Still Unstable!
Project: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/ Build: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/1091/ Build Number: 1091 Build Status: Still Unstable Triggered By: Triggered by Gerrit: http://gerrit.ovirt.org/35968 - Changes Since Last Success: - Changes for Build #1088 [Tomer Saban] webadmin: CPU shares custom value is now possible Changes for Build #1089 [Gilad Chaplik] webadmin: fix cpu profile changes for import Changes for Build #1090 [Vitor de Lima] core, engine: Disable CPU pinning validation Changes for Build #1091 [Maor Lipchuk] webadmin: Remove Storage connection on import domain failure - Failed Tests: - No tests ran. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
[oVirt Jenkins] ovirt-engine_3.5_find-bugs_merged - Build # 1089 - Unstable!
Project: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/ Build: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/1089/ Build Number: 1089 Build Status: Unstable Triggered By: Triggered by Gerrit: http://gerrit.ovirt.org/35960 - Changes Since Last Success: - Changes for Build #1088 [Tomer Saban] webadmin: CPU shares custom value is now possible Changes for Build #1089 [Gilad Chaplik] webadmin: fix cpu profile changes for import - Failed Tests: - No tests ran. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
[oVirt Jenkins] ovirt-engine_3.5_find-bugs_merged - Build # 1090 - Still Unstable!
Project: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/ Build: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/1090/ Build Number: 1090 Build Status: Still Unstable Triggered By: Triggered by Gerrit: http://gerrit.ovirt.org/35760 - Changes Since Last Success: - Changes for Build #1088 [Tomer Saban] webadmin: CPU shares custom value is now possible Changes for Build #1089 [Gilad Chaplik] webadmin: fix cpu profile changes for import Changes for Build #1090 [Vitor de Lima] core, engine: Disable CPU pinning validation - Failed Tests: - No tests ran. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
[oVirt Jenkins] ovirt-engine_3.5_find-bugs_merged - Build # 1088 - Failure!
Project: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/ Build: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/1088/ Build Number: 1088 Build Status: Failure Triggered By: Triggered by Gerrit: http://gerrit.ovirt.org/35956 - Changes Since Last Success: - Changes for Build #1088 [Tomer Saban] webadmin: CPU shares custom value is now possible - Failed Tests: - No tests ran. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Logwatch for linode01.ovirt.org (Linux)
### Logwatch 7.3.6 (05/19/07)
Processing Initiated: Tue Dec 9 03:11:15 2014
Date Range Processed: yesterday
( 2014-Dec-08 )
Period is day.
Detail Level of Output: 0
Type of Output: unformatted
Logfiles for Host: linode01.ovirt.org
##
- httpd Begin
Requests with error response codes
400 Bad Request
/: 1 Time(s)
/pipermail/engine-commits/2012-july01088.html: 1 Time(s)
/pipermail/users/2013-february12758.html: 2 Time(s)
/pub/src/%{name}-%{package_version}.tar.gz: 1 Time(s)
/pub/src/%{name}/%{name}-%{package_version}.tar.gz: 1 Time(s)
404 Not Found
//administrator/components/com_jnewsletter ... ?name=hajar.php: 1 Time(s)
//administrator/components/com_jnewsletter ... mages/hajar.php: 1 Time(s)
//components/com_facileforms/libraries/jquery/uploadify.php: 1 Time(s)
//config.old.php?jom: 1 Time(s)
//images/stories/roin.gif: 1 Time(s)
//images/stories/sono.gif: 1 Time(s)
//wp-content/themes/Envisioned//thumb.php? ... .sk/mods/sh.php: 1 Time(s)
//wp-content/themes/Envisioned//timthumb.p ... .sk/mods/sh.php: 1 Time(s)
//wp-content/themes/Envisioned/custom/thum ... .sk/mods/sh.php: 1 Time(s)
//wp-content/themes/Envisioned/custom/timt ... .sk/mods/sh.php: 1 Time(s)
//wp-content/themes/Envisioned/framework/i ... .sk/mods/sh.php: 2 Time(s)
//wp-content/themes/Envisioned/framework/t ... .sk/mods/sh.php: 2 Time(s)
//wp-content/themes/Envisioned/functions/s ... .sk/mods/sh.php: 2 Time(s)
//wp-content/themes/Envisioned/functions/t ... .sk/mods/sh.php: 4 Time(s)
//wp-content/themes/Envisioned/images/thum ... .sk/mods/sh.php: 1 Time(s)
//wp-content/themes/Envisioned/images/timt ... .sk/mods/sh.php: 1 Time(s)
//wp-content/themes/Envisioned/inc/thumb.p ... .sk/mods/sh.php: 1 Time(s)
//wp-content/themes/Envisioned/inc/timthum ... .sk/mods/sh.php: 1 Time(s)
//wp-content/themes/Envisioned/includes/th ... .sk/mods/sh.php: 4 Time(s)
//wp-content/themes/Envisioned/includes/ti ... .sk/mods/sh.php: 2 Time(s)
//wp-content/themes/Envisioned/js/thumb.ph ... .sk/mods/sh.php: 1 Time(s)
//wp-content/themes/Envisioned/js/timthumb ... .sk/mods/sh.php: 1 Time(s)
//wp-content/themes/Envisioned/layouts/thu ... .sk/mods/sh.php: 1 Time(s)
//wp-content/themes/Envisioned/layouts/tim ... .sk/mods/sh.php: 1 Time(s)
//wp-content/themes/Envisioned/lib/custom/ ... .sk/mods/sh.php: 2 Time(s)
//wp-content/themes/Envisioned/lib/script/ ... .sk/mods/sh.php: 2 Time(s)
//wp-content/themes/Envisioned/lib/thumb.p ... .sk/mods/sh.php: 1 Time(s)
//wp-content/themes/Envisioned/lib/thumb/t ... .sk/mods/sh.php: 3 Time(s)
//wp-content/themes/Envisioned/lib/timthum ... .sk/mods/sh.php: 2 Time(s)
//wp-content/themes/Envisioned/library/fun ... .sk/mods/sh.php: 2 Time(s)
//wp-content/themes/Envisioned/library/res ... .sk/mods/sh.php: 2 Time(s)
//wp-content/themes/Envisioned/library/thu ... .sk/mods/sh.php: 4 Time(s)
//wp-content/themes/Envisioned/library/tim ... .sk/mods/sh.php: 2 Time(s)
//wp-content/themes/Envisioned/modules/thu ... .sk/mods/sh.php: 1 Time(s)
//wp-content/themes/Envisioned/modules/tim ... .sk/mods/sh.php: 1 Time(s)
//wp-content/themes/Envisioned/options/thu ... .sk/mods/sh.php: 1 Time(s)
//wp-content/themes/Envisioned/options/tim ... .sk/mods/sh.php: 1 Time(s)
//wp-content/themes/Envisioned/scripts/thu ... .sk/mods/sh.php: 4 Time(s)
//wp-content/themes/Envisioned/scripts/tim ... .sk/mods/sh.php: 2 Time(s)
//wp-content/themes/Envisioned/thumb/thumb ... .sk/mods/sh.php: 2 Time(s)
//wp-content/themes/Envisioned/thumb/timth ... .sk/mods/sh.php: 1 Time(s)
//wp-content/themes/Envisioned/timthumb/ti ... .sk/mods/sh.php: 1 Time(s)
//wp-content/themes/Envisioned/tools/thumb ... .sk/mods/sh.php: 4 Time(s)
//wp-content/themes/Envisioned/tools/timth ... .sk/mods/sh.php: 2 Time(s)
//wp-content/themes/bueno//thumb.php?src=h ... .sk/mods/sh.php: 2 Time(s)
//wp-content/themes/bueno//timthumb.php?sr ... .sk/mods/sh.php: 2 Time(s)
//wp-content/themes/bueno/custom/thumb.php ... .sk/mods/sh.php: 2 Time(s)
//wp-content/themes/bueno/custom/timthumb. ... .sk/mods/sh.php: 2 Time(s)
//wp-content/themes/bueno/framework/includ ... .sk/mods/sh.php: 4 Time(s)
//wp-content/themes/bueno/framework/thumb/ ... .sk/mods/sh.php: 4 Time(s)
//wp-content/themes/bueno/functions/script ... .sk/mods/sh.php: 4 Time(s)
//wp-content/themes/bueno/functions/thumb. ... .sk/mods/sh.php: 2 Time(s)
//wp-content/themes/bueno/functions/thu
[oVirt Jenkins] ovirt-engine_3.5_find-bugs_merged - Build # 1085 - Fixed!
Project: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/ Build: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/1085/ Build Number: 1085 Build Status: Fixed Triggered By: Triggered by Gerrit: http://gerrit.ovirt.org/35402 - Changes Since Last Success: - Changes for Build #1084 [pkliczewski] rest: Validation of the protocol values Changes for Build #1085 [Tomer Saban] webadmin: Fixed misalignment 'Copy Quota' dialog. - Failed Tests: - No tests ran. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
[oVirt Jenkins] ovirt-engine_3.5_find-bugs_merged - Build # 1084 - Unstable!
Project: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/ Build: http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/1084/ Build Number: 1084 Build Status: Unstable Triggered By: Triggered by Gerrit: http://gerrit.ovirt.org/35898 - Changes Since Last Success: - Changes for Build #1084 [pkliczewski] rest: Validation of the protocol values - Failed Tests: - No tests ran. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
