INFRA ISSUE: [oVirt Jenkins] ovirt-engine_3.5_upgrade-from-3.4_merged - Build # 1472 - 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/1472/ Build Number: 1472 Build Status: Failure Triggered By: Triggered by Gerrit: https://gerrit.ovirt.org/40508 - Changes Since Last Success: - Changes for Build #1472 [Alon Bar-Lev] packaging: setup: pki: renew about to expire certificates [Sandro Bonazzola] fix centos 7 base repo - Failed Tests: - No tests ran. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: your patch https://gerrit.ovirt.org/#/c/40346/ broke oVirt vdsm jobs
On Tue, May 05, 2015 at 10:11:09AM +0200, David Caro wrote: On 05/05, Max Kovgan wrote: hi, Dan. makes sense to me to focus on 2 use cases: - pre-commit hook running everything jenkins is running - locally Maybe pre-push instead, that will leverage a bit the local work - pros: - nearly identical checks/tests jenkins would running - doesn't care about IDE/editor - cons: - slower - can be annoying to commit (locally) broken code for later squashing If something is too anoying to be run (such as blocking every patch for 3 minute unit tests, when the poor developer only wants to post his patch and go home) - developer would find a way to skip it. - editor/IDE marriage with tests/checks running - pros: - dev has full control over what runs in checks/tests - allows to commit dirty commit - shorter == quicker than the quickest jenkins option - cons: - depends on IDE/editor support - less checks/tests = higher risk +1. It boils down to developer and maintainer prudence. I have such a plugin in my ViM for static testing; Ido (and everyone else) should have one, too. I'm less sure about auto-running `make check` at rundom points in time. I did both with: intelliJ/PyCharm and vim, almost 100% sure PyDev allows this. either allows ease of running tests - in 1st case upon git commit, in the latter - via a button/shortcut in the devtool. I can help with setting up either to an early adopter. Then give it a week or two to get some feedback later how well it goes. Besides, we're also trying to speedup jenkins response all the time I would not mind to BLOCK merging before jenkins hook has responded - assuming that I (as a branch maintainer) can remove the jenkins reviewer from gerrit. There could be emenrgencies that cannot wait for the response. And of course, as a maintainer, I must be able to override the decision of the robot (by removing it from the reviewer list). ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: your patch https://gerrit.ovirt.org/#/c/40346/ broke oVirt vdsm jobs
On 05/05, Dan Kenigsberg wrote: On Tue, May 05, 2015 at 10:11:09AM +0200, David Caro wrote: On 05/05, Max Kovgan wrote: hi, Dan. makes sense to me to focus on 2 use cases: - pre-commit hook running everything jenkins is running - locally Maybe pre-push instead, that will leverage a bit the local work - pros: - nearly identical checks/tests jenkins would running - doesn't care about IDE/editor - cons: - slower - can be annoying to commit (locally) broken code for later squashing If something is too anoying to be run (such as blocking every patch for 3 minute unit tests, when the poor developer only wants to post his patch and go home) - developer would find a way to skip it. - editor/IDE marriage with tests/checks running - pros: - dev has full control over what runs in checks/tests - allows to commit dirty commit - shorter == quicker than the quickest jenkins option - cons: - depends on IDE/editor support - less checks/tests = higher risk +1. It boils down to developer and maintainer prudence. I have such a plugin in my ViM for static testing; Ido (and everyone else) should have one, too. I'm less sure about auto-running `make check` at rundom points in time. I did both with: intelliJ/PyCharm and vim, almost 100% sure PyDev allows this. either allows ease of running tests - in 1st case upon git commit, in the latter - via a button/shortcut in the devtool. I can help with setting up either to an early adopter. Then give it a week or two to get some feedback later how well it goes. Besides, we're also trying to speedup jenkins response all the time I would not mind to BLOCK merging before jenkins hook has responded - assuming that I (as a branch maintainer) can remove the jenkins reviewer from gerrit. There could be emenrgencies that cannot wait for the response. And of course, as a maintainer, I must be able to override the decision of the robot (by removing it from the reviewer list). I'm actually working on adding a new flag 'Continuous Integration' that can only be set by maintainers and the ci bot, and that requires +1 to merge (where -1 does not block). Does that make sense to you? (that way you can't rebase and merge before ci runs and -1, it's easier to handle permissions, it's easier to spot on the ui, is clearer it's purpose and does not overload another flag). -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization RD Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 pgpc5HfLQhfHR.pgp Description: PGP signature ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
vdsm_master_install-rpm-sanity-el7_created broken - reason unclear
Hi infra, This job fails, but I could not find why It looks like this job failed before trying to install the rpms, so this is an infra issue, and the job should show on gerrit as ERROR, and not as FAILURE. These are the only errors seen in the log. 16:40:48 ERROR: Exception(/home/jenkins/workspace/vdsm_master_install-rpm-sanity-el7_created/exported-artifacts/vdsm-4.17.0-766.git9a98879.fc21.src.rpm) Config(epel-7-x86_64-ovirt-snapshot) 3 minutes 14 seconds 16:40:49 ERROR: dracut-install: ERROR: installing 'vi' 16:40:49 dracut-install: ERROR: installing '/etc/virc' Please disable this job until it is reliable, and has proper error reporting. Thanks, Nir [1] http://jenkins.ovirt.org/job/vdsm_master_install-rpm-sanity-el7_created/911/console ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Fedora 22 build broken - missing gluster repo
Hi infra, We have a problem with fc22_created job [1] It fails with: 16:17:34 Error: nothing provides glusterfs = 3.6.999 needed by vdsm-4.17.0-762.git6e3659a.fc22.x86_64. This means it does not have the gluster development repository [2], providing gluster 3.7. Please disable this job until the job is configured properly. Thanks, Nir [1] http://jenkins.ovirt.org/job/vdsm_master_install-rpm-sanity-fc22_created/127/console [2] http://www.ovirt.org/Vdsm_Developers#Installing_the_required_packages ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Fedora 22 build broken - missing gluster repo
On Tue, May 05, 2015 at 12:16:12PM -0400, Nir Soffer wrote: Hi infra, We have a problem with fc22_created job [1] It fails with: 16:17:34 Error: nothing provides glusterfs = 3.6.999 needed by vdsm-4.17.0-762.git6e3659a.fc22.x86_64. This means it does not have the gluster development repository [2], providing gluster 3.7. Please disable this job until the job is configured properly. Thanks, Nir [1] http://jenkins.ovirt.org/job/vdsm_master_install-rpm-sanity-fc22_created/127/console [2] http://www.ovirt.org/Vdsm_Developers#Installing_the_required_packages That job should have been disabled per my request to support DNF [3] as yum is missing from f22. [3] https://fedorahosted.org/ovirt/ticket/317 ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: stopping/aborting obsolete jenkins jobs
On 05/05, Eli Mesika wrote: - Original Message - From: Yedidyah Bar David d...@redhat.com To: Infra infra@ovirt.org Sent: Tuesday, May 5, 2015 8:26:43 AM Subject: stopping/aborting obsolete jenkins jobs Hi, It happened to me quite a lot lately, that I pushed a new patchset for a change, before jenkins finished running relevant jobs for previous patchsets, in some cases even before it started running some of them. Perhaps in such a case we should stop (if running) or disable/abort (if not yet running) all the jobs except for the ones running for the latest patchset? Happens to me a lot I think that it should be automatic and if you are pushing version x+1 then if version x jobs are still running , it will be aborted Afaik, that behavior is only supported by zuul. So not something that we can easily change. This will both give quicker results for the dev/maint and lower the load on the slaves. Best, -- Didi ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization RD Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 pgpCnKPnPr536.pgp Description: PGP signature ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Change in ovirt-engine[master]: packaging: add provisiondb
- Original Message - From: Barak Korren bkor...@redhat.com To: Yedidyah Bar David d...@redhat.com Cc: Infra infra@ovirt.org Sent: Tuesday, May 5, 2015 10:04:41 AM Subject: Re: Change in ovirt-engine[master]: packaging: add provisiondb Yhea someone at some point writing some job decided to always blame infra for everything... convenient... it was my idea of differentiating jobs that are failing unexpectedly, usually red jobs without output, which during that time was only jobs failing due to infra errors. before we moved to PHX lab, we had very limited resources so unfourtunately there was lots of infra errors. we're in a different place today, and maybe its worth to remove this remark, as developers should contact infra anyway if they can't understand the reason for failure. e. - Original Message - From: Yedidyah Bar David d...@redhat.com To: Infra infra@ovirt.org Sent: Monday, May 4, 2015 5:28:03 PM Subject: Re: Change in ovirt-engine[master]: packaging: add provisiondb - Original Message - From: Jenkins CI gerr...@gerrit.ovirt.org To: Yedidyah Bar David d...@redhat.com Sent: Monday, May 4, 2015 5:11:21 PM Subject: Change in ovirt-engine[master]: packaging: add provisiondb Jenkins CI has posted comments on this change. Change subject: packaging: add provisiondb .. Patch Set 7: Build Failed http://jenkins.ovirt.org/job/ovirt-engine_master_create-rpms-quick_gerrit/7445/ : There was an infra issue, please contact infra@ovirt.org It was a simple pep8 violation, not an infra issue. -- Didi ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ 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 May 5 03:46:03 2015 Date Range Processed: yesterday ( 2015-May-04 ) 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 /: 2 Time(s) 404 Not Found /**mailman/listinfo/usershttp:/lists.ovir ... /listinfo/users: 1 Time(s) /.libs.php: 3 Time(s) //dompdf.php: 8 Time(s) //dompdf.php?input_file=http://www.yc57.com/.mods//bt.php?: 4 Time(s) //dompdf.php?input_file=http://www.yc57.com/.mods//sh.txt?: 5 Time(s) //index.php?option=com_jdownloadsItemid=0view=upload: 3 Time(s) //skin/ggambo7002_board/write.phpdir=remote??: 1 Time(s) /_: 1 Time(s) /_h5ai/client/icons/96/folder.png: 1 Time(s) /_h5ai/client/images/app-16x16.ico: 19 Time(s) /_h5ai/client/images/crumb.svg: 24 Time(s) /_h5ai/client/images/home.svg: 24 Time(s) /_h5ai/client/images/preview/prev.svg: 1 Time(s) /admin.php: 10 Time(s) /admin/: 9 Time(s) /admin/banner_manager.php/login.php?action=insert: 3 Time(s) /admin/board: 1 Time(s) /admin/categories.php/login.php?cPath=act ... product_preview: 3 Time(s) /admin/file_manager.php/login.php?action=d ... s/configure.php: 3 Time(s) /admin/file_manager.php/login.php?action=processuploads: 3 Time(s) /admin/login.php: 9 Time(s) /admin/wp-login.php: 1 Time(s) /administrator/: 2 Time(s) /administrator/components/com_acymailing/i ... ?name=magic.php: 7 Time(s) /administrator/components/com_acymailing/i ... e=magic.php.pHp: 7 Time(s) /administrator/components/com_civicrm/civi ... ?name=magic.php: 7 Time(s) /administrator/components/com_civicrm/civi ... e=magic.php.pHp: 7 Time(s) /administrator/components/com_jinc/classes ... ?name=magic.php: 7 Time(s) /administrator/components/com_jinc/classes ... e=magic.php.pHp: 7 Time(s) /administrator/components/com_jnews/includ ... ?name=magic.php: 7 Time(s) /administrator/components/com_jnews/includ ... e=magic.php.pHp: 7 Time(s) /administrator/components/com_jnewsletter/ ... ?name=magic.php: 7 Time(s) /administrator/components/com_jnewsletter/ ... e=magic.php.pHp: 7 Time(s) /administrator/components/com_maian15/char ... ?name=magic.php: 7 Time(s) /administrator/components/com_maian15/char ... e=magic.php.pHp: 7 Time(s) /administrator/index.php: 9 Time(s) /apple-touch-icon-precomposed.png: 2 Time(s) /apple-touch-icon.png: 2 Time(s) /asal.php: 3 Time(s) /bitrix/admin/index.php?lang=en: 9 Time(s) /blog/wp-admin/: 17 Time(s) /blog/wp-login.php: 1 Time(s) /board: 2 Time(s) /category/news/feed: 1 Time(s) /category/news/feed/: 21 Time(s) /cms/wp-login.php: 1 Time(s) /components/com_acymailing/inc/openflash/p ... ?name=magic.php: 7 Time(s) /components/com_acymailing/inc/openflash/p ... e=magic.php.pHp: 7 Time(s) /components/com_civicrm/civicrm/packages/O ... ?name=magic.php: 7 Time(s) /components/com_civicrm/civicrm/packages/O ... e=magic.php.pHp: 7 Time(s) /components/com_jinc/classes/graphics/php- ... ?name=magic.php: 7 Time(s) /components/com_jinc/classes/graphics/php- ... e=magic.php.pHp: 7 Time(s) /components/com_jnews/includes/openflashch ... ?name=magic.php: 7 Time(s) /components/com_jnews/includes/openflashch ... e=magic.php.pHp: 7 Time(s) /components/com_jnewsletter/includes/openf ... ?name=magic.php: 7 Time(s) /components/com_jnewsletter/includes/openf ... e=magic.php.pHp: 7 Time(s) /components/com_maian15/charts/php-ofc-lib ... ?name=magic.php: 7 Time(s) /components/com_maian15/charts/php-ofc-lib ... e=magic.php.pHp: 7 Time(s) /favicon.ico: 626 Time(s) /flashgallery.php?sohai: 3 Time(s) /images/jdownloads/screenshots/thumbnails.php.j: 1 Time(s) /images/jdownloads/screenshots/thumbnails.php.j?rf: 1 Time(s) /index.php?option=com_userview=resetlayout=confirm: 1 Time(s) /listinfo/board: 1 Time(s) /listinfo/board:: 1 Time(s) /listinfo/infra: 1 Time(s) /old/wp-admin/: 18 Time(s) /pi:: 1 Time(s) /pipermail/board/2014-April/001095.html+++ ... F0%E0%E2%EA%E8;: 1 Time(s) /pipermail/commits: 1 Time(s) /pipermail/devel/2013-April/004273.html/trackback/: 2 Time(s) /pipermail/engine-devel/2013-April/004135.html/trackback/: 2 Time(s) /pipermail/engine-patches/2011-December/001594.html: 1 Time(s)
Re: Change in ovirt-engine[master]: packaging: add provisiondb
Yhea someone at some point writing some job decided to always blame infra for everything... convenient... - Original Message - From: Yedidyah Bar David d...@redhat.com To: Infra infra@ovirt.org Sent: Monday, May 4, 2015 5:28:03 PM Subject: Re: Change in ovirt-engine[master]: packaging: add provisiondb - Original Message - From: Jenkins CI gerr...@gerrit.ovirt.org To: Yedidyah Bar David d...@redhat.com Sent: Monday, May 4, 2015 5:11:21 PM Subject: Change in ovirt-engine[master]: packaging: add provisiondb Jenkins CI has posted comments on this change. Change subject: packaging: add provisiondb .. Patch Set 7: Build Failed http://jenkins.ovirt.org/job/ovirt-engine_master_create-rpms-quick_gerrit/7445/ : There was an infra issue, please contact infra@ovirt.org It was a simple pep8 violation, not an infra issue. -- Didi ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: stopping/aborting obsolete jenkins jobs
- Original Message - From: Yedidyah Bar David d...@redhat.com To: Infra infra@ovirt.org Sent: Tuesday, May 5, 2015 8:26:43 AM Subject: stopping/aborting obsolete jenkins jobs Hi, It happened to me quite a lot lately, that I pushed a new patchset for a change, before jenkins finished running relevant jobs for previous patchsets, in some cases even before it started running some of them. Perhaps in such a case we should stop (if running) or disable/abort (if not yet running) all the jobs except for the ones running for the latest patchset? Happens to me a lot I think that it should be automatic and if you are pushing version x+1 then if version x jobs are still running , it will be aborted This will both give quicker results for the dev/maint and lower the load on the slaves. Best, -- Didi ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: stopping/aborting obsolete jenkins jobs
- Original Message - From: Yedidyah Bar David d...@redhat.com To: Infra infra@ovirt.org Sent: Tuesday, May 5, 2015 8:26:43 AM Subject: stopping/aborting obsolete jenkins jobs Hi, It happened to me quite a lot lately, that I pushed a new patchset for a change, before jenkins finished running relevant jobs for previous patchsets, in some cases even before it started running some of them. Perhaps in such a case we should stop (if running) or disable/abort (if not yet running) all the jobs except for the ones running for the latest patchset? not sure its possible, but its not something that you want to do (aggressive interrupt jenkins running or queue) This will both give quicker results for the dev/maint and lower the load on the slaves. we are working on improving this on 2 fronts: 1. adding more slaves 2. reducing job running time (findbugs is currently being optimized) and you're welcome to join the effort of getting there next monday, on the infra hackathon :) [1] [1] https://docs.google.com/spreadsheets/d/1PGGqI5tT_pmF7HUdg63FlozuVoQOBQaO-VID_R2eZqE/edit#gid=0 Best, -- Didi ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: your patch https://gerrit.ovirt.org/#/c/40346/ broke oVirt vdsm jobs
On 05/05, Max Kovgan wrote: hi, Dan. makes sense to me to focus on 2 use cases: - pre-commit hook running everything jenkins is running - locally Maybe pre-push instead, that will leverage a bit the local work - pros: - nearly identical checks/tests jenkins would running - doesn't care about IDE/editor - cons: - slower - can be annoying to commit (locally) broken code for later squashing - editor/IDE marriage with tests/checks running - pros: - dev has full control over what runs in checks/tests - allows to commit dirty commit - shorter == quicker than the quickest jenkins option - cons: - depends on IDE/editor support - less checks/tests = higher risk I did both with: intelliJ/PyCharm and vim, almost 100% sure PyDev allows this. either allows ease of running tests - in 1st case upon git commit, in the latter - via a button/shortcut in the devtool. I can help with setting up either to an early adopter. Then give it a week or two to get some feedback later how well it goes. Besides, we're also trying to speedup jenkins response all the time WDYT? On Wed, Apr 29, 2015 at 10:57:14PM +0100, Dan Kenigsberg wrote: On Wed, Apr 29, 2015 at 11:16:37AM -0400, Barak Korren wrote: Patch does not pass pyflakes: ./tests/samplingTests.py:30: 'libvirtconnection' imported but unused ./tests/samplingTests.py:36: 'MonkeyPatch' imported but unused make: *** [pyflakes] Error 1 You could clearly see that the tests did not pass for patchset #6 Please do not merge patches with failing tests! Barak, thanks for reporting this mistake of ours. https://gerrit.ovirt.org/#/c/40408/ would fix it momentarily. I believe that it stems from two reasons: - Ido did not run `make check` or `make pyflakes` before ticking verified on the patch - I failed to wait for the jenkins job to finish. To make sure that this does not repeat I should avoid merging freshly-posted patches. Ido should take better care for pep8 and pyflakes. I have vim plugins that help me avoid such mistakes I hear that http://www.vim.org/scripts/script.php?script_id=4440 is better than what I actually have. Regards, Dan. ---end quoted text--- -- Max Kovgan Senior Software Engineer Red Hat - EMEA ENG Virtualization RD Tel.: +972 9769 2060 Email: mkovgan [at] redhat [dot] com Web: http://www.redhat.com RHT Global #: 82-72060 ___ 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 RD Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 pgpyShd7PFMfv.pgp Description: PGP signature ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: your patch https://gerrit.ovirt.org/#/c/40346/ broke oVirt vdsm jobs
On Tue, May 05, 2015 at 05:18:00PM +0200, David Caro wrote: On 05/05, Dan Kenigsberg wrote: On Tue, May 05, 2015 at 10:11:09AM +0200, David Caro wrote: On 05/05, Max Kovgan wrote: hi, Dan. makes sense to me to focus on 2 use cases: - pre-commit hook running everything jenkins is running - locally Maybe pre-push instead, that will leverage a bit the local work - pros: - nearly identical checks/tests jenkins would running - doesn't care about IDE/editor - cons: - slower - can be annoying to commit (locally) broken code for later squashing If something is too anoying to be run (such as blocking every patch for 3 minute unit tests, when the poor developer only wants to post his patch and go home) - developer would find a way to skip it. - editor/IDE marriage with tests/checks running - pros: - dev has full control over what runs in checks/tests - allows to commit dirty commit - shorter == quicker than the quickest jenkins option - cons: - depends on IDE/editor support - less checks/tests = higher risk +1. It boils down to developer and maintainer prudence. I have such a plugin in my ViM for static testing; Ido (and everyone else) should have one, too. I'm less sure about auto-running `make check` at rundom points in time. I did both with: intelliJ/PyCharm and vim, almost 100% sure PyDev allows this. either allows ease of running tests - in 1st case upon git commit, in the latter - via a button/shortcut in the devtool. I can help with setting up either to an early adopter. Then give it a week or two to get some feedback later how well it goes. Besides, we're also trying to speedup jenkins response all the time I would not mind to BLOCK merging before jenkins hook has responded - assuming that I (as a branch maintainer) can remove the jenkins reviewer from gerrit. There could be emenrgencies that cannot wait for the response. And of course, as a maintainer, I must be able to override the decision of the robot (by removing it from the reviewer list). I'm actually working on adding a new flag 'Continuous Integration' that can only be set by maintainers and the ci bot, and that requires +1 to merge (where -1 does not block). Does that make sense to you? (that way you can't rebase and merge before ci runs and -1, it's easier to handle permissions, it's easier to spot on the ui, is clearer it's purpose and does not overload another flag). Yes, it does! ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: stopping/aborting obsolete jenkins jobs
- Original Message - From: Eyal Edri ee...@redhat.com To: Yedidyah Bar David d...@redhat.com Cc: Infra infra@ovirt.org Sent: Tuesday, May 5, 2015 10:19:57 AM Subject: Re: stopping/aborting obsolete jenkins jobs - Original Message - From: Eyal Edri ee...@redhat.com To: Yedidyah Bar David d...@redhat.com Cc: Infra infra@ovirt.org Sent: Tuesday, May 5, 2015 10:15:21 AM Subject: Re: stopping/aborting obsolete jenkins jobs - Original Message - From: Yedidyah Bar David d...@redhat.com To: Infra infra@ovirt.org Sent: Tuesday, May 5, 2015 8:26:43 AM Subject: stopping/aborting obsolete jenkins jobs Hi, It happened to me quite a lot lately, that I pushed a new patchset for a change, before jenkins finished running relevant jobs for previous patchsets, in some cases even before it started running some of them. Perhaps in such a case we should stop (if running) or disable/abort (if not yet running) all the jobs except for the ones running for the latest patchset? not sure its possible, but its not something that you want to do (aggressive interrupt jenkins running or queue) This will both give quicker results for the dev/maint and lower the load on the slaves. we are working on improving this on 2 fronts: 1. adding more slaves 2. reducing job running time (findbugs is currently being optimized) forgot one more thing - we added a new flag called 'workflow' which we are testing now on the jenkins project. this flag means that the developer marks: my code is ready for review (might not be verified yet, since he wants early engagement before running a verification). For jenkins it means that only when a developer will mark +1 on this patch the jenkins jobs will start running on it (instead of running per patchset). so if we're OK in adding this flag to engine/vdsm - it will reduce dramatically the amount of running jobs. +1 , I am totally for it, we are waiting ages for tests completion so this flag will be great ... and you're welcome to join the effort of getting there next monday, on the infra hackathon :) [1] [1] https://docs.google.com/spreadsheets/d/1PGGqI5tT_pmF7HUdg63FlozuVoQOBQaO-VID_R2eZqE/edit#gid=0 Best, -- Didi ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ 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: stopping/aborting obsolete jenkins jobs
- Original Message - From: Eli Mesika emes...@redhat.com To: Eyal Edri ee...@redhat.com Cc: Yedidyah Bar David d...@redhat.com, Infra infra@ovirt.org Sent: Tuesday, May 5, 2015 1:42:47 PM Subject: Re: stopping/aborting obsolete jenkins jobs - Original Message - From: Eyal Edri ee...@redhat.com To: Yedidyah Bar David d...@redhat.com Cc: Infra infra@ovirt.org Sent: Tuesday, May 5, 2015 10:19:57 AM Subject: Re: stopping/aborting obsolete jenkins jobs - Original Message - From: Eyal Edri ee...@redhat.com To: Yedidyah Bar David d...@redhat.com Cc: Infra infra@ovirt.org Sent: Tuesday, May 5, 2015 10:15:21 AM Subject: Re: stopping/aborting obsolete jenkins jobs - Original Message - From: Yedidyah Bar David d...@redhat.com To: Infra infra@ovirt.org Sent: Tuesday, May 5, 2015 8:26:43 AM Subject: stopping/aborting obsolete jenkins jobs Hi, It happened to me quite a lot lately, that I pushed a new patchset for a change, before jenkins finished running relevant jobs for previous patchsets, in some cases even before it started running some of them. Perhaps in such a case we should stop (if running) or disable/abort (if not yet running) all the jobs except for the ones running for the latest patchset? not sure its possible, but its not something that you want to do (aggressive interrupt jenkins running or queue) This will both give quicker results for the dev/maint and lower the load on the slaves. we are working on improving this on 2 fronts: 1. adding more slaves 2. reducing job running time (findbugs is currently being optimized) forgot one more thing - we added a new flag called 'workflow' which we are testing now on the jenkins project. this flag means that the developer marks: my code is ready for review (might not be verified yet, since he wants early engagement before running a verification). For jenkins it means that only when a developer will mark +1 on this patch the jenkins jobs will start running on it (instead of running per patchset). so if we're OK in adding this flag to engine/vdsm - it will reduce dramatically the amount of running jobs. +1 , I am totally for it, we are waiting ages for tests completion so this flag will be great ... for the immediate time, we can also restrict jobs to run only on +verified or +1, this is one of the tasks for next week's hackathon. and you're welcome to join the effort of getting there next monday, on the infra hackathon :) [1] [1] https://docs.google.com/spreadsheets/d/1PGGqI5tT_pmF7HUdg63FlozuVoQOBQaO-VID_R2eZqE/edit#gid=0 Best, -- Didi ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ 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: stopping/aborting obsolete jenkins jobs
Il 05/05/2015 12:42, Eli Mesika ha scritto: - Original Message - From: Eyal Edri ee...@redhat.com To: Yedidyah Bar David d...@redhat.com Cc: Infra infra@ovirt.org Sent: Tuesday, May 5, 2015 10:19:57 AM Subject: Re: stopping/aborting obsolete jenkins jobs - Original Message - From: Eyal Edri ee...@redhat.com To: Yedidyah Bar David d...@redhat.com Cc: Infra infra@ovirt.org Sent: Tuesday, May 5, 2015 10:15:21 AM Subject: Re: stopping/aborting obsolete jenkins jobs - Original Message - From: Yedidyah Bar David d...@redhat.com To: Infra infra@ovirt.org Sent: Tuesday, May 5, 2015 8:26:43 AM Subject: stopping/aborting obsolete jenkins jobs Hi, It happened to me quite a lot lately, that I pushed a new patchset for a change, before jenkins finished running relevant jobs for previous patchsets, in some cases even before it started running some of them. Perhaps in such a case we should stop (if running) or disable/abort (if not yet running) all the jobs except for the ones running for the latest patchset? not sure its possible, but its not something that you want to do (aggressive interrupt jenkins running or queue) This will both give quicker results for the dev/maint and lower the load on the slaves. we are working on improving this on 2 fronts: 1. adding more slaves 2. reducing job running time (findbugs is currently being optimized) forgot one more thing - we added a new flag called 'workflow' which we are testing now on the jenkins project. this flag means that the developer marks: my code is ready for review (might not be verified yet, since he wants early engagement before running a verification). For jenkins it means that only when a developer will mark +1 on this patch the jenkins jobs will start running on it (instead of running per patchset). so if we're OK in adding this flag to engine/vdsm - it will reduce dramatically the amount of running jobs. +1 , I am totally for it, we are waiting ages for tests completion so this flag will be great ... +1 and you're welcome to join the effort of getting there next monday, on the infra hackathon :) [1] [1] https://docs.google.com/spreadsheets/d/1PGGqI5tT_pmF7HUdg63FlozuVoQOBQaO-VID_R2eZqE/edit#gid=0 Best, -- Didi ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ 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 -- 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
