July 2017 - Infra - oVirt List Archives

[JIRA] (OVIRT-1502) gerrit does not print check_merged output
by ybronhei (oVirt JIRA) 03 Jul '17

03 Jul '17

ybronhei created OVIRT-1502: ------------------------------- Summary: gerrit does not print check_merged output Key: OVIRT-1502 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1502 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: ybronhei Assignee: infra Hello, Recently vdsm gerrit job check-merged doesn't send report after its done - check all recent jobs - they were done but the gerrit url doesn't show the output nor send email about failures. Thanks in advance Yaniv Bronhaim. -- Yaniv Bronhaim. -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

1 0

[JIRA] (OVIRT-1501) Jenkins slave is stuck on virsh cleanup
by Daniel Belenky (oVirt JIRA) 03 Jul '17

03 Jul '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1501?page=com.atlassian.jira.… ] Daniel Belenky updated OVIRT-1501: ---------------------------------- Summary: Jenkins slave is stuck on virsh cleanup (was: Jenkins slave is stuck on libvirt cleanup) > Jenkins slave is stuck on virsh cleanup > --------------------------------------- > > Key: OVIRT-1501 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1501 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Daniel Belenky > Assignee: infra > > Jenkins slave was stuck on virsh cleanup. > The following job: [Link|http://jenkins.ovirt.org/job/ovirt-node-ng_master_build-artifacts-el7-…] timed out after 6 hours. > The next job that tried to run on the same slave [link|http://jenkins.ovirt.org/job/ovirt-node-ng_master_build-artifacts-el7-…] couldn't destroy the domain. > I couldn't manually destroy the domain either, and I've ended up rebooting the VM. > The slave that was rebooted: vm0015.workers-phx.ovirt.org. -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

1 0

[JIRA] (OVIRT-1501) Jenkins slave is stuck on libvirt cleanup
by Daniel Belenky (oVirt JIRA) 03 Jul '17

03 Jul '17

Daniel Belenky created OVIRT-1501: ------------------------------------- Summary: Jenkins slave is stuck on libvirt cleanup Key: OVIRT-1501 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1501 Project: oVirt - virtualization made easy Issue Type: Bug Reporter: Daniel Belenky Assignee: infra Jenkins slave was stuck on virsh cleanup. The following job: [Link|http://jenkins.ovirt.org/job/ovirt-node-ng_master_build-artifacts-el7-…] timed out after 6 hours. The next job that tried to run on the same slave [link|http://jenkins.ovirt.org/job/ovirt-node-ng_master_build-artifacts-el7-…] couldn't destroy the domain. I couldn't manually destroy the domain either, and I've ended up rebooting the VM. The slave that was rebooted: vm0015.workers-phx.ovirt.org. -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

1 0

[oVirt Jenkins] standard-enqueue - Build #2224 - FAILURE!
by jenkins＠jenkins.phx.ovirt.org 03 Jul '17

03 Jul '17

------=_Part_122_48570426.1499075611183 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.ovirt.org/job/standard-enqueue/2224/ Build Name: 2224 ovirt-engine (master) Build Status: FAILURE Gerrit change: https://gerrit.ovirt.org/78902 - title: core: remove unused fields in update cluster - project: ovirt-engine - branch: master - author: Arik Hadas <ahadas(a)redhat.com> ------=_Part_122_48570426.1499075611183--

1 0

[oVirt Jenkins] deploy-to-ovirt_experimental - Build #3038 - FAILURE!
by jenkins＠jenkins.phx.ovirt.org 03 Jul '17

03 Jul '17

------=_Part_120_1793821833.1499073008613 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.ovirt.org/job/deploy-to-ovirt_experimental/3038/ Build Name: 3038 ovirt-engine-api-metamodel (master) Build Status: FAILURE Gerrit change: https://gerrit.ovirt.org/75083 - title: Live Documentation - Auto validation - project: ovirt-engine-api-metamodel - branch: master - author: Ori Liel <oliel(a)redhat.com> ------=_Part_120_1793821833.1499073008613--

1 0

[oVirt Jenkins] deploy-to-ovirt_experimental - Build #3036 - FAILURE!
by jenkins＠jenkins.phx.ovirt.org 03 Jul '17

03 Jul '17

------=_Part_118_1305787878.1499072396254 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.ovirt.org/job/deploy-to-ovirt_experimental/3036/ Build Name: 3036 ovirt-engine-api-metamodel (master) Build Status: FAILURE Gerrit change: https://gerrit.ovirt.org/77793 - title: Generate doGet, doList methods - project: ovirt-engine-api-metamodel - branch: master - author: Ori Liel <oliel(a)redhat.com> ------=_Part_118_1305787878.1499072396254--

1 0

[JIRA] (OVIRT-1500) CI on ovirt-engine patch succeeded, but didn't mark CI=+1 on gerrit
by Allon Mureinik (oVirt JIRA) 03 Jul '17

03 Jul '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1500?page=com.atlassian.jira.… ] Allon Mureinik edited comment on OVIRT-1500 at 7/3/17 11:52 AM: ---------------------------------------------------------------- {quote} So i'm not sure which inheritance are you reffering to, CI shouldn't run on patchset #2 since it was just commit msg update and returned +1 on the 1st patchset, no? {quote} Eyal - the behavior of just marking patchset #1 with CI=+1 is correct. I want this value *copied* to patchset #2, so it's visible from gerrit's dashboard. Otherwise, I need to see there's no CI score on the dashboard, go into this patch, read through the history to understand why it was never triggered on patchset #2 and mark CI=+1 myself (or manually trigger) in order to merge. Nothing here is technically "wrong", but it's a poor UX for gerrit users, and we should strive to improve it if possible. was (Author: mureinik): > So i'm not sure which inheritance are you reffering to, CI shouldn't run on patchset #2 since it was just commit msg update and returned +1 on the 1st patchset, no? Eyal - the behavior of just marking patchset #1 with CI=+1 is correct. I want this value **copied** to patchset #2, so it's visible from gerrit's dashboard. Otherwise, I need to see there's no CI score on the dashboard, go into this patch, read through the history to understand why it was never triggered on patchset #2 and mark CI=+1 myself (or manually trigger) in order to merge. Nothing here is technically "wrong", but it's a poor UX for gerrit users, and we should strive to improve it if possible. > CI on ovirt-engine patch succeeded, but didn't mark CI=+1 on gerrit > ------------------------------------------------------------------- > > Key: OVIRT-1500 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1500 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Gerrit/git, oVirt CI > Reporter: Allon Mureinik > Assignee: infra > > In my recent engine patch https://gerrit.ovirt.org/#/c/78911 the CI passed, but was not marked as so in gerrit. > Looking through gerrit's history, here's what I *think* is going on: > 08:41 - patchset #1 is submitted > 08:41 - CI (check-patch) starts for both EL7 and fc25 > _At this point I noticed a typo in the commit method. I fixed it and posted patchset #2_ > 08:42 - patchset #2 is submitted > _CI was never triggered for patchset #2. Is this because the only difference between it and patchset #1 is the commit message?_ > 09:15 - CI for patchset #1 completes, and marks *patchset #1* with CI=+1. This is not inherited to patchset #2 for some reason. > Expected behavior: > If CI for patchset #1 passed and the only difference is the commit message (not the parent commit and not the content), I'd expect the CI score to be inherited. -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

1 0

[JIRA] (OVIRT-1500) CI on ovirt-engine patch succeeded, but didn't mark CI=+1 on gerrit
by Allon Mureinik (oVirt JIRA) 03 Jul '17

03 Jul '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1500?page=com.atlassian.jira.… ] Allon Mureinik commented on OVIRT-1500: --------------------------------------- > So i'm not sure which inheritance are you reffering to, CI shouldn't run on patchset #2 since it was just commit msg update and returned +1 on the 1st patchset, no? Eyal - the behavior of just marking patchset #1 with CI=+1 is correct. I want this value **copied** to patchset #2, so it's visible from gerrit's dashboard. Otherwise, I need to see there's no CI score on the dashboard, go into this patch, read through the history to understand why it was never triggered on patchset #2 and mark CI=+1 myself (or manually trigger) in order to merge. Nothing here is technically "wrong", but it's a poor UX for gerrit users, and we should strive to improve it if possible. > CI on ovirt-engine patch succeeded, but didn't mark CI=+1 on gerrit > ------------------------------------------------------------------- > > Key: OVIRT-1500 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1500 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Gerrit/git, oVirt CI > Reporter: Allon Mureinik > Assignee: infra > > In my recent engine patch https://gerrit.ovirt.org/#/c/78911 the CI passed, but was not marked as so in gerrit. > Looking through gerrit's history, here's what I *think* is going on: > 08:41 - patchset #1 is submitted > 08:41 - CI (check-patch) starts for both EL7 and fc25 > _At this point I noticed a typo in the commit method. I fixed it and posted patchset #2_ > 08:42 - patchset #2 is submitted > _CI was never triggered for patchset #2. Is this because the only difference between it and patchset #1 is the commit message?_ > 09:15 - CI for patchset #1 completes, and marks *patchset #1* with CI=+1. This is not inherited to patchset #2 for some reason. > Expected behavior: > If CI for patchset #1 passed and the only difference is the commit message (not the parent commit and not the content), I'd expect the CI score to be inherited. -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

1 0

[JIRA] (OVIRT-1468) Use CI mirrors for the slaves
by eedri (oVirt JIRA) 03 Jul '17

03 Jul '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1468?page=com.atlassian.jira.… ] eedri commented on OVIRT-1468: ------------------------------ Let's discuss on the next CI meeting. > Use CI mirrors for the slaves > ----------------------------- > > Key: OVIRT-1468 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1468 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: oVirt Infra > Reporter: Barak Korren > Assignee: infra > Priority: High > Labels: jenkins, mirrors, slaves > > Since we've seen that issues like OVIRT-1467 can very quickly break our entire infrastructure, it may be advisable to use out mirrors to isolate the slave VMs from the upstream repos as well, and not just the testing environments. -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

1 0

[JIRA] (OVIRT-1468) Use CI mirrors for the slaves
by eedri (oVirt JIRA) 03 Jul '17

03 Jul '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1468?page=com.atlassian.jira.… ] eedri updated OVIRT-1468: ------------------------- Priority: High (was: Medium) > Use CI mirrors for the slaves > ----------------------------- > > Key: OVIRT-1468 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1468 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: oVirt Infra > Reporter: Barak Korren > Assignee: infra > Priority: High > Labels: jenkins, mirrors, slaves > > Since we've seen that issues like OVIRT-1467 can very quickly break our entire infrastructure, it may be advisable to use out mirrors to isolate the slave VMs from the upstream repos as well, and not just the testing environments. -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

1 0