July 2017 - Infra - Ovirt List Archives

Change 78890,3 (vdsm) failed system tests

by oVirt Jenkins

A system test invoked by the "ovirt-master" change queue including change 78890,3 (vdsm) failed. However, this change seems not to be to root cause for failure. Change 78630,13 (vdsm) that this change depends on or is based on, was detected to cause testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 78630,13 (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/78890/3 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/78630/13 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/1039/

7 years, 4 months

1
0
0 / 0

[JIRA] (OVIRT-1434) Re: Every user can abandon patches that are not his

by Shlomo Ben David (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1434?page=com.atlassian.jir... ] Shlomo Ben David updated OVIRT-1434: ------------------------------------ Resolution: Fixed Status: Done (was: To Do) > Re: Every user can abandon patches that are not his > --------------------------------------------------- > > Key: OVIRT-1434 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1434 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: eedri > Assignee: Shlomo Ben David > > Adding infra support to open a ticket. > On Wed, Jun 7, 2017 at 3:11 PM, Tal Nisan <tnisan(a)redhat.com> wrote: > > Hi, > > I've discovered that every user can abandon patches even if they are not > > his, here's an example of Shani abandoning my patch which shouldn't be > > allowed: > > > > https://gerrit.ovirt.org/#/c/77919/ > > > > > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > -- > Eyal edri > ASSOCIATE MANAGER > RHV DevOps > EMEA VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > phone: +972-9-7692018 > irc: eedri (on #tlv #rhev-dev #rhev-integ) -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

7 years, 4 months

1
0
0 / 0

[JIRA] (OVIRT-1434) Re: Every user can abandon patches that are not his

by Shlomo Ben David (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1434?page=com.atlassian.jir... ] Shlomo Ben David commented on OVIRT-1434: ----------------------------------------- yes, with this patch: https://gerrit.ovirt.org/#/c/77941/ > Re: Every user can abandon patches that are not his > --------------------------------------------------- > > Key: OVIRT-1434 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1434 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: eedri > Assignee: Shlomo Ben David > > Adding infra support to open a ticket. > On Wed, Jun 7, 2017 at 3:11 PM, Tal Nisan <tnisan(a)redhat.com> wrote: > > Hi, > > I've discovered that every user can abandon patches even if they are not > > his, here's an example of Shani abandoning my patch which shouldn't be > > allowed: > > > > https://gerrit.ovirt.org/#/c/77919/ > > > > > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > -- > Eyal edri > ASSOCIATE MANAGER > RHV DevOps > EMEA VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > phone: +972-9-7692018 > irc: eedri (on #tlv #rhev-dev #rhev-integ) -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

7 years, 4 months

1
0
0 / 0

[oVirt Jenkins] test-repo_ovirt_experimental_4.1 - Build #1800 - FAILURE!

by jenkins＠jenkins.phx.ovirt.org

------=_Part_145_102059630.1499098923494 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4.1/1800/, Build Number: 1800, Build Status: FAILURE ------=_Part_145_102059630.1499098923494--

7 years, 4 months

1
1
0 / 0

[JIRA] (OVIRT-1252) post-merge build-artifacts jobs can run out of order

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1252?page=com.atlassian.jir... ] Barak Korren commented on OVIRT-1252: ------------------------------------- [~eedri] yes. for when using build-artifats as a yum repo with the latestStableBuild link. > post-merge build-artifacts jobs can run out of order > ---------------------------------------------------- > > Key: OVIRT-1252 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1252 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Barak Korren > Assignee: infra > Labels: standard-ci > > Right now build-artifacts jobs that run post merge get run on every patch and are allowed to run in parallel. > The end result of this is that they do not always finish in the same order in which the patches were merged. This ends up causing the latest build link in Jenkins to not always point to the real latest build. It may also means that packages get pushed to OST not in the right order. > To fix this we need to make sure the build-artifacts jobs do not run in parallel. Alternatively we could split the build artifacts job into a trigger job and a builder job where the trigger job gets run on every patch in parallel and the builder job only runs where resources are available. -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

7 years, 4 months

1
0
0 / 0

[JIRA] (OVIRT-1162) Make sure cron failure email from resources.ovirt.org reach the infra list

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1162?page=com.atlassian.jir... ] Barak Korren commented on OVIRT-1162: ------------------------------------- [~eedri] actually I made the nightly publisher jobs check if cron ran and fail (with unstable) otherwise when I made it sync from tested. So this is probably not highly needed any more. > Make sure cron failure email from resources.ovirt.org reach the infra list > -------------------------------------------------------------------------- > > Key: OVIRT-1162 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1162 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Repositories Mgmt > Reporter: Barak Korren > Assignee: infra > Priority: High > > There are quite a few things that run there with cron and we need to know when they fail. -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

7 years, 4 months

1
0
0 / 0

[JIRA] (OVIRT-886) Yum install does not throw error on missing package

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-886?page=com.atlassian.jira... ] Barak Korren commented on OVIRT-886: ------------------------------------ [~eedri] no this is actually a known issue, ticket should remain open. It can be easily fixed as long as we're using mock though. > Yum install does not throw error on missing package > --------------------------------------------------- > > Key: OVIRT-886 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-886 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Gil Shinar > Assignee: infra > > When running el7 mock on fc24 (not necessary the issue) and one of the required packages is missing because a repository in .repos hadn't been added, yum will not fail and the package will not be installed -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

7 years, 4 months

1
0
0 / 0

[JIRA] (OVIRT-1014) avoid repetition in automation/*packages

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1014?page=com.atlassian.jir... ] Barak Korren commented on OVIRT-1014: ------------------------------------- [~eedri(a)redaht.com] actually it seems I linked to the wrong one. Which ticket are we using to track V2 again? > avoid repetition in automation/*packages > ---------------------------------------- > > Key: OVIRT-1014 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1014 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: danken > Assignee: infra > Labels: standard-ci > > Currently we have many automation/*packages* files, mostly repeating each other. > Most of the information there is then repeated in vdsm.spec as well. > It would be nice to have a hierarchical way to define packages. E.g. having most packages in automation/build-artifacts-manual.packages, and adding el7-specific dependencies in avoid repetition in automation/build-artifacts-manual.packages.el7. > It would be even better to have a single palce (yaml file?) to declare each required package and its version, for each platform/architecture. We can then use it to generate the spec file. -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

7 years, 4 months

1
0
0 / 0

[JIRA] (OVIRT-1014) avoid repetition in automation/*packages

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1014?page=com.atlassian.jir... ] Barak Korren commented on OVIRT-1014: ------------------------------------- [~eedri] linking. > avoid repetition in automation/*packages > ---------------------------------------- > > Key: OVIRT-1014 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1014 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: danken > Assignee: infra > Labels: standard-ci > > Currently we have many automation/*packages* files, mostly repeating each other. > Most of the information there is then repeated in vdsm.spec as well. > It would be nice to have a hierarchical way to define packages. E.g. having most packages in automation/build-artifacts-manual.packages, and adding el7-specific dependencies in avoid repetition in automation/build-artifacts-manual.packages.el7. > It would be even better to have a single palce (yaml file?) to declare each required package and its version, for each platform/architecture. We can then use it to generate the spec file. -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

7 years, 4 months

1
0
0 / 0

[JIRA] (OVIRT-1014) avoid repetition in automation/*packages

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1014?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1014: -------------------------------- Labels: standard-ci (was: ) > avoid repetition in automation/*packages > ---------------------------------------- > > Key: OVIRT-1014 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1014 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: danken > Assignee: infra > Labels: standard-ci > > Currently we have many automation/*packages* files, mostly repeating each other. > Most of the information there is then repeated in vdsm.spec as well. > It would be nice to have a hierarchical way to define packages. E.g. having most packages in automation/build-artifacts-manual.packages, and adding el7-specific dependencies in avoid repetition in automation/build-artifacts-manual.packages.el7. > It would be even better to have a single palce (yaml file?) to declare each required package and its version, for each platform/architecture. We can then use it to generate the spec file. -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

7 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Infra July 2017