December 2018 - Infra - Ovirt List Archives

[CQ]: 252c21d (ovirt-ansible-engine-setup) failed "ovirt-master" system tests

by oVirt Jenkins

Change 252c21d (ovirt-ansible-engine-setup) is probably the reason behind recent system test failures in the "ovirt-master" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://github.com/oVirt/ovirt-ansible-engine-setup/commit/252c21d708e0e9... For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/11850/

5 years, 11 months

1
0
0 / 0

[CQ]: f81f7ce (ovirt-ansible) failed "ovirt-master" system tests

by oVirt Jenkins

Change f81f7ce (ovirt-ansible) is probably the reason behind recent system test failures in the "ovirt-master" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://github.com/oVirt/ovirt-ansible/commit/f81f7ce0eb7ec1c8babc6afd49e... For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/11848/

5 years, 11 months

1
0
0 / 0

[CQ]: a1e4392 (ovirt-ansible) failed "ovirt-4.2" system tests

by oVirt Jenkins

Change a1e4392 (ovirt-ansible) is probably the reason behind recent system test failures in the "ovirt-4.2" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://github.com/oVirt/ovirt-ansible/commit/a1e439270f84e4ee422996fc5b5... For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/3582/

5 years, 11 months

1
0
0 / 0

[CQ]: 95746, 11 (vdsm) failed "ovirt-master" system tests, but isn't the failure root cause

by oVirt Jenkins

A system test invoked by the "ovirt-master" change queue including change 95746,11 (vdsm) failed. However, this change seems not to be the root cause for this failure. Change 95911,1 (vdsm) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 95911,1 (vdsm) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/95746/11 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/95911/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/11846/

5 years, 11 months

1
0
0 / 0

[CQ]: 95746, 11 (vdsm) failed "ovirt-master" system tests, but isn't the failure root cause

by oVirt Jenkins

A system test invoked by the "ovirt-master" change queue including change 95746,11 (vdsm) failed. However, this change seems not to be the root cause for this failure. Change 95911,1 (vdsm) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 95911,1 (vdsm) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/95746/11 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/95911/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/11843/

5 years, 11 months

1
0
0 / 0

[CQ]: 252c21d (ovirt-ansible-engine-setup) failed "ovirt-4.2" system tests

by oVirt Jenkins

Change 252c21d (ovirt-ansible-engine-setup) is probably the reason behind recent system test failures in the "ovirt-4.2" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://github.com/oVirt/ovirt-ansible-engine-setup/commit/252c21d708e0e9... For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/3581/

5 years, 11 months

1
0
0 / 0

[JIRA] (OVIRT-2609) stdci style reports sometimes disappear pretty fast

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2609?page=com.atlassian.jir... ] Barak Korren reassigned OVIRT-2609: ----------------------------------- Assignee: Ehud Yonasi (was: infra) > stdci style reports sometimes disappear pretty fast > --------------------------------------------------- > > Key: OVIRT-2609 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2609 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Roman Mohr > Assignee: Ehud Yonasi > > Can there be a SLA defined for how long we can see test results until they > get removed? > It does not have to be like on travis (where I can still see all my build > logs from years ago), but at least a predictable period would be nice. The > PR in [1] did for instance not have the results anymore from 5 days ago. > Thanks, > Roman > [1] https://github.com/kubevirt/kubevirt/pull/1744 -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

5 years, 11 months

1
0
0 / 0

[JIRA] (OVIRT-2609) stdci style reports sometimes disappear pretty fast

by Roman Mohr (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2609?page=com.atlassian.jir... ] Roman Mohr commented on OVIRT-2609: ----------------------------------- [~bkorren(a)redhat.com] you see them because I triggered them today again. > stdci style reports sometimes disappear pretty fast > --------------------------------------------------- > > Key: OVIRT-2609 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2609 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Roman Mohr > Assignee: infra > > Can there be a SLA defined for how long we can see test results until they > get removed? > It does not have to be like on travis (where I can still see all my build > logs from years ago), but at least a predictable period would be nice. The > PR in [1] did for instance not have the results anymore from 5 days ago. > Thanks, > Roman > [1] https://github.com/kubevirt/kubevirt/pull/1744 -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

5 years, 11 months

1
0
0 / 0

[JIRA] (OVIRT-2609) stdci style reports sometimes disappear pretty fast

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2609?page=com.atlassian.jir... ] Barak Korren commented on OVIRT-2609: ------------------------------------- Its kept for 14 days, looking at the linked PR, I still see results there: https://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/2735/ar... I do see we also have a setting to keep only the last 60 built artifacts, we may want to remove that. > stdci style reports sometimes disappear pretty fast > --------------------------------------------------- > > Key: OVIRT-2609 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2609 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Roman Mohr > Assignee: infra > > Can there be a SLA defined for how long we can see test results until they > get removed? > It does not have to be like on travis (where I can still see all my build > logs from years ago), but at least a predictable period would be nice. The > PR in [1] did for instance not have the results anymore from 5 days ago. > Thanks, > Roman > [1] https://github.com/kubevirt/kubevirt/pull/1744 -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

5 years, 11 months

1
0
0 / 0

Space issues on lfedora1.lf-dev.marist.edu

by Barak Korren

Hi Dan, How are you. As you know we've been using `lfedora1.lf-dev.marist.edu` to generate s390x build of oVirt. We've recently seen some failures that have to do with running our of space on the node. Some of this seems to be our fault, as clearing up stale mock chroots we created freed up about 14G, but after doing that I still see there are 48G used there (Is the OS image that big?). Can some more space be cleared up on the node? Could we perhaps have the disk space increased there? I was also wondering, could we setup and use Docker on that node? We've been switching to using containers on our regular CI nodes, and it'd be a shame to leave s390x behind... Thanks, Barak. -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted

5 years, 11 months

2
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Infra December 2018