February 2019 - Infra - Ovirt List Archives

[JIRA] (OVIRT-2666) OST fails with LagoDeployError: ... failed with status 1 on lago-basic-suite-master-host-0

by Dafna Ron (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2666?page=com.atlassian.jir... ] Dafna Ron commented on OVIRT-2666: ---------------------------------- Galit merged a fix and upstream is fix. Closing this as resolved. Please re-open if this is still happening for you. > OST fails with LagoDeployError: ... failed with status 1 on lago-basic-suite-master-host-0 > ------------------------------------------------------------------------------------------ > > Key: OVIRT-2666 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2666 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Nir Soffer > Assignee: infra > Labels: ost_failures, ost_packages > > I had 2 OST failure today with the same infrastructure failure, before > running any test: > + install_cmd='yum install --nogpgcheck --downloaddir=/dev/shm -y' > + yum install --nogpgcheck --downloaddir=/dev/shm -y ntp net-snmp > ovirt-engine ovirt-log-collector 'ovirt-engine-extension-aaa-ldap*' > otopi-debug-plugins cronie > Error: Package: 7:device-mapper-event-1.02.149-10.el7_6.3.x86_64 > (alocalsync) > Requires: device-mapper = 7:1.02.149-10.el7_6.3 > Installed: 7:device-mapper-1.02.149-10.el7_6.2.x86_64 (installed) > device-mapper = 7:1.02.149-10.el7_6.2 > ret=1 > + echo 'install failed with status 1' > + exit 1 > - STDERR > Links to failed builds: > - > https://jenkins.ovirt.org/blue/organizations/jenkins/ovirt-system-tests_m... > - > https://jenkins.ovirt.org/blue/organizations/jenkins/ovirt-system-tests_m... > The last successful build was at Feb 1: > https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4004/ > The trend show that all builds failed since Feb 3 9:02 am. > https://jenkins.ovirt.org/job/ovirt-system-tests_manual/buildTimeTrend > This issue is blocking 4.3 work on 4k support. > Nir -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100098)

5 years, 2 months

1
0
0 / 0

[JIRA] (OVIRT-2669) CI scripts try to modify unrelated bugs

by Ehud Yonasi (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2669?page=com.atlassian.jir... ] Ehud Yonasi updated OVIRT-2669: ------------------------------- Resolution: Duplicate Status: Done (was: To Do) > CI scripts try to modify unrelated bugs > --------------------------------------- > > Key: OVIRT-2669 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2669 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Nir Soffer > Assignee: infra > > If a commit message mention another bug, the CI script try to add the patch > to the bug in the commit message, and change the bug to POST. > Mentioning another bug in a commit message is good practice, making it > easier to follow, and avoiding unclear forms like "bug 1000000" or > "BZ#1000000", > or even worse shortened urls like https://goo.gl/bPuFGo. > Does it make sense that we cannot link to Red Hat bugzilla like god > intended? > Here is a proof: > https://gerrit.ovirt.org/c/97568/ > gerrit-hooks > Patch Set 1: > Check Bug-Url::10000000::WARN, failed to get bug info (private bug or > bug doesn't exist > Check Product::IGNORE, not relevant for branch: master > Check TM::IGNORE, not relevant for branch: master > Check Backport::IGNORE, not relevant for branch: master > Set POST::#10000000::WARN, failed to get bug info (private bug or bug > doesn't exist) > Update Tracker::#10000000::WARN, failed to get bug info (private bug or > bug doesn't exist) > CI scripts should process urls only inside Bug-Url: tag. > Expected behavior: > Extract bug urls *only* from Bug-Url: label. > The same issue exists with Related-To: label. > This is not a new bug. I reported it few years ago but for some reason the > issue > was not understood. > Nir -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100098)

5 years, 2 months

1
0
0 / 0

[JIRA] (OVIRT-2669) CI scripts try to modify unrelated bugs

by Ehud Yonasi (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2669?page=com.atlassian.jir... ] Ehud Yonasi commented on OVIRT-2669: ------------------------------------ Closing this ticket, opening in d/s jira. > CI scripts try to modify unrelated bugs > --------------------------------------- > > Key: OVIRT-2669 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2669 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Nir Soffer > Assignee: infra > > If a commit message mention another bug, the CI script try to add the patch > to the bug in the commit message, and change the bug to POST. > Mentioning another bug in a commit message is good practice, making it > easier to follow, and avoiding unclear forms like "bug 1000000" or > "BZ#1000000", > or even worse shortened urls like https://goo.gl/bPuFGo. > Does it make sense that we cannot link to Red Hat bugzilla like god > intended? > Here is a proof: > https://gerrit.ovirt.org/c/97568/ > gerrit-hooks > Patch Set 1: > Check Bug-Url::10000000::WARN, failed to get bug info (private bug or > bug doesn't exist > Check Product::IGNORE, not relevant for branch: master > Check TM::IGNORE, not relevant for branch: master > Check Backport::IGNORE, not relevant for branch: master > Set POST::#10000000::WARN, failed to get bug info (private bug or bug > doesn't exist) > Update Tracker::#10000000::WARN, failed to get bug info (private bug or > bug doesn't exist) > CI scripts should process urls only inside Bug-Url: tag. > Expected behavior: > Extract bug urls *only* from Bug-Url: label. > The same issue exists with Related-To: label. > This is not a new bug. I reported it few years ago but for some reason the > issue > was not understood. > Nir -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100098)

5 years, 2 months

1
0
0 / 0

[JENKINS] Failed to setup proejct kubevirt_kubevirt_standard-check-pr

by jenkins＠jenkins.phx.ovirt.org

Failed to run project_setup.sh for: #3436 kubevirt [check-patch]. It probably means that docker_cleanup.py failed. This step doesn't fail the job, but we do collect data about such failures to find the root cause. Infra owner, ensure that we're not running out of disk space on openshift-kubevirt-org-xxlnf.

5 years, 2 months

1
0
0 / 0

[JENKINS] Failed to setup proejct kubevirt_kubevirt_standard-check-pr

by jenkins＠jenkins.phx.ovirt.org

Failed to run project_setup.sh for: #3433 kubevirt [check-patch]. It probably means that docker_cleanup.py failed. This step doesn't fail the job, but we do collect data about such failures to find the root cause. Infra owner, ensure that we're not running out of disk space on openshift-kubevirt-org-n1p89.

5 years, 2 months

1
0
0 / 0

[JIRA] (OVIRT-2669) CI scripts try to modify unrelated bugs

by Nir Soffer (oVirt JIRA)

Nir Soffer created OVIRT-2669: --------------------------------- Summary: CI scripts try to modify unrelated bugs Key: OVIRT-2669 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2669 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Nir Soffer Assignee: infra If a commit message mention another bug, the CI script try to add the patch to the bug in the commit message, and change the bug to POST. Mentioning another bug in a commit message is good practice, making it easier to follow, and avoiding unclear forms like "bug 1000000" or "BZ#1000000", or even worse shortened urls like https://goo.gl/bPuFGo. Does it make sense that we cannot link to Red Hat bugzilla like god intended? Here is a proof: https://gerrit.ovirt.org/c/97568/ gerrit-hooks Patch Set 1: Check Bug-Url::10000000::WARN, failed to get bug info (private bug or bug doesn't exist Check Product::IGNORE, not relevant for branch: master Check TM::IGNORE, not relevant for branch: master Check Backport::IGNORE, not relevant for branch: master Set POST::#10000000::WARN, failed to get bug info (private bug or bug doesn't exist) Update Tracker::#10000000::WARN, failed to get bug info (private bug or bug doesn't exist) CI scripts should process urls only inside Bug-Url: tag. Expected behavior: Extract bug urls *only* from Bug-Url: label. The same issue exists with Related-To: label. This is not a new bug. I reported it few years ago but for some reason the issue was not understood. Nir -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100098)

5 years, 2 months

1
0
0 / 0

CI scripts try to modify unrelated bugs

by Nir Soffer

If a commit message mention another bug, the CI script try to add the patch to the bug in the commit message, and change the bug to POST. Mentioning another bug in a commit message is good practice, making it easier to follow, and avoiding unclear forms like "bug 1000000" or "BZ#1000000", or even worse shortened urls like https://goo.gl/bPuFGo. Does it make sense that we cannot link to Red Hat bugzilla like god intended? Here is a proof: https://gerrit.ovirt.org/c/97568/ gerrit-hooks Patch Set 1: Check Bug-Url::10000000::WARN, failed to get bug info (private bug or bug doesn't exist Check Product::IGNORE, not relevant for branch: master Check TM::IGNORE, not relevant for branch: master Check Backport::IGNORE, not relevant for branch: master Set POST::#10000000::WARN, failed to get bug info (private bug or bug doesn't exist) Update Tracker::#10000000::WARN, failed to get bug info (private bug or bug doesn't exist) CI scripts should process urls only inside Bug-Url: tag. Expected behavior: Extract bug urls *only* from Bug-Url: label. The same issue exists with Related-To: label. This is not a new bug. I reported it few years ago but for some reason the issue was not understood. Nir

5 years, 2 months

1
0
0 / 0

[JIRA] (OVIRT-2668) WildFly 15 packages got to tested-4.3 repo, but not to tested-master repo

by Ehud Yonasi (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2668?page=com.atlassian.jir... ] Ehud Yonasi reassigned OVIRT-2668: ---------------------------------- Assignee: Ehud Yonasi (was: infra) > WildFly 15 packages got to tested-4.3 repo, but not to tested-master repo > ------------------------------------------------------------------------- > > Key: OVIRT-2668 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2668 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Martin Perina > Assignee: Ehud Yonasi > > Hi, > I have a problem with publishing WildFly 15 packages to tested repos for master and 4.3. I've merged [#97474|https://gerrit.ovirt.org/97474] and next day I've found out that [ovirt-engine-wildfly-15.0.1-1.el7.x86_64.rpm|https://plain.resources.ovir...] and [ovirt-engine-wildfly-overlay-15.0.1-1.el7.noarch.rpm|https://plain.resour...] packages appeared in ovirt-4.3 tested repo, but they were not published to master-tested repo, although I have both branches mentioned in [stdci.yaml|https://github.com/oVirt/ovirt-engine-wildfly/blob/master/stdc...] in the project. > Is it some issue with stdci.yaml or something went wrong in CQ publishing? > The absence of WildFly 15 in master-tested repo blocks finishing of [BZ1671635|https://bugzilla.redhat.com/1671635]. > Thanks > Martin -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100098)

5 years, 2 months

1
0
0 / 0

[JIRA] (OVIRT-2668) WildFly 15 packages got to tested-4.3 repo, but not to tested-master repo

by Ehud Yonasi (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2668?page=com.atlassian.jir... ] Ehud Yonasi commented on OVIRT-2668: ------------------------------------ Hi [~mwperina], It was published into master CQ, but since there was a packaging issue that was solved today, all master cq jobs failed. I've re-added your patch into the cq system and if it passes CQ, it should be published to tested. > WildFly 15 packages got to tested-4.3 repo, but not to tested-master repo > ------------------------------------------------------------------------- > > Key: OVIRT-2668 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2668 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Martin Perina > Assignee: infra > > Hi, > I have a problem with publishing WildFly 15 packages to tested repos for master and 4.3. I've merged [#97474|https://gerrit.ovirt.org/97474] and next day I've found out that [ovirt-engine-wildfly-15.0.1-1.el7.x86_64.rpm|https://plain.resources.ovir...] and [ovirt-engine-wildfly-overlay-15.0.1-1.el7.noarch.rpm|https://plain.resour...] packages appeared in ovirt-4.3 tested repo, but they were not published to master-tested repo, although I have both branches mentioned in [stdci.yaml|https://github.com/oVirt/ovirt-engine-wildfly/blob/master/stdc...] in the project. > Is it some issue with stdci.yaml or something went wrong in CQ publishing? > The absence of WildFly 15 in master-tested repo blocks finishing of [BZ1671635|https://bugzilla.redhat.com/1671635]. > Thanks > Martin -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100098)

5 years, 2 months

1
0
0 / 0

[JIRA] (OVIRT-2668) WildFly 15 packages got to tested-4.3 repo, but not to tested-master repo

by Martin Perina (oVirt JIRA)

Martin Perina created OVIRT-2668: ------------------------------------ Summary: WildFly 15 packages got to tested-4.3 repo, but not to tested-master repo Key: OVIRT-2668 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2668 Project: oVirt - virtualization made easy Issue Type: Bug Reporter: Martin Perina Assignee: infra Hi, I have a problem with publishing WildFly 15 packages to tested repos for master and 4.3. I've merged [#97474|https://gerrit.ovirt.org/97474] and next day I've found out that [ovirt-engine-wildfly-15.0.1-1.el7.x86_64.rpm|https://plain.resources.ovir...] and [ovirt-engine-wildfly-overlay-15.0.1-1.el7.noarch.rpm|https://plain.resour...] packages appeared in ovirt-4.3 tested repo, but they were not published to master-tested repo, although I have both branches mentioned in [stdci.yaml|https://github.com/oVirt/ovirt-engine-wildfly/blob/master/stdc...] in the project. Is it some issue with stdci.yaml or something went wrong in CQ publishing? The absence of WildFly 15 in master-tested repo blocks finishing of [BZ1671635|https://bugzilla.redhat.com/1671635]. Thanks Martin -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100098)

5 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Infra February 2019