June 2018 - Infra - Ovirt List Archives

[JIRA] (OVIRT-1737) cleanup_lago method in cleanup_slave.sh should have a return status

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1737?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1737: -------------------------------- Epic Link: (was: OVIRT-400) > cleanup_lago method in cleanup_slave.sh should have a return status > ------------------------------------------------------------------- > > Key: OVIRT-1737 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1737 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Jenkins Slaves > Reporter: Daniel Belenky > Assignee: infra > Priority: Low > > Currently, the method doesn't return the return code from it's submethods to 'main'. This needs to be fixed. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years, 6 months

1
0
0 / 0

[JIRA] (OVIRT-1737) cleanup_lago method in cleanup_slave.sh should have a return status

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1737?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1737: -------------------------------- Epic Link: (was: OVIRT-400) > cleanup_lago method in cleanup_slave.sh should have a return status > ------------------------------------------------------------------- > > Key: OVIRT-1737 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1737 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Jenkins Slaves > Reporter: Daniel Belenky > Assignee: infra > Priority: Low > > Currently, the method doesn't return the return code from it's submethods to 'main'. This needs to be fixed. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years, 6 months

1
0
0 / 0

[JIRA] (OVIRT-1737) cleanup_lago method in cleanup_slave.sh should have a return status

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1737?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1737: -------------------------------- Component/s: Jenkins Slaves > cleanup_lago method in cleanup_slave.sh should have a return status > ------------------------------------------------------------------- > > Key: OVIRT-1737 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1737 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Jenkins Slaves > Reporter: Daniel Belenky > Assignee: infra > Priority: Low > > Currently, the method doesn't return the return code from it's submethods to 'main'. This needs to be fixed. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years, 6 months

1
0
0 / 0

[JIRA] (OVIRT-1739) Unified code owners mechanism between Gerrit and GitHub

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1739?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1739: -------------------------------- Epic Link: (was: OVIRT-400) > Unified code owners mechanism between Gerrit and GitHub > ------------------------------------------------------- > > Key: OVIRT-1739 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1739 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Gerrit/git, GitHub, Standard CI (Freestyle), Standard CI (Pipelines), STDCI DSL > Reporter: Barak Korren > Assignee: infra > Labels: gerrit, github, reviewers, standard-ci > > "Code owners" is the mechanism that automatically assigns reviewers to new code patches. > In Gerrit we use the "reviewers" plugin to automatically set reviewers (See OVIRT-1165). > GitHub has its own mechanism: https://github.com/blog/2392-introducing-code-owners > We would like to have a unified way for oVirt devs to do this regardless of the code hosting platform. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years, 6 months

1
0
0 / 0

[JIRA] (OVIRT-1739) Unified code owners mechanism between Gerrit and GitHub

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1739?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1739: -------------------------------- Epic Link: (was: OVIRT-400) > Unified code owners mechanism between Gerrit and GitHub > ------------------------------------------------------- > > Key: OVIRT-1739 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1739 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Gerrit/git, GitHub, Standard CI (Freestyle), Standard CI (Pipelines), STDCI DSL > Reporter: Barak Korren > Assignee: infra > Labels: gerrit, github, reviewers, standard-ci > > "Code owners" is the mechanism that automatically assigns reviewers to new code patches. > In Gerrit we use the "reviewers" plugin to automatically set reviewers (See OVIRT-1165). > GitHub has its own mechanism: https://github.com/blog/2392-introducing-code-owners > We would like to have a unified way for oVirt devs to do this regardless of the code hosting platform. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years, 6 months

1
0
0 / 0

[JIRA] (OVIRT-1743) ci please build and send to OST

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1743?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1743: -------------------------------- Epic Link: (was: OVIRT-400) > ci please build and send to OST > ------------------------------- > > Key: OVIRT-1743 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1743 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: OST Manual job, Standard CI (Freestyle) > Reporter: danken > Assignee: infra > Labels: change-queue > > Can you please automate the frequent process, which is slow and error prone? > I am writing a patch, and would like to test it in ost. now I need to > * "ci please build" > * copy el7 url > * wait for el7 build to finish > * copy artifacts url to ovirt--system-test-manual, start it > * copy the ost run URL to the gerrit patch, so I have it for reference of failure/success. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years, 6 months

1
0
0 / 0

[JIRA] (OVIRT-1743) ci please build and send to OST

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1743?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1743: -------------------------------- Epic Link: (was: OVIRT-400) > ci please build and send to OST > ------------------------------- > > Key: OVIRT-1743 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1743 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: OST Manual job, Standard CI (Freestyle) > Reporter: danken > Assignee: infra > Labels: change-queue > > Can you please automate the frequent process, which is slow and error prone? > I am writing a patch, and would like to test it in ost. now I need to > * "ci please build" > * copy el7 url > * wait for el7 build to finish > * copy artifacts url to ovirt--system-test-manual, start it > * copy the ost run URL to the gerrit patch, so I have it for reference of failure/success. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years, 6 months

1
0
0 / 0

[JIRA] (OVIRT-1759) Gerrit patches can reach CQ out-of-order

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1759?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1759: -------------------------------- Epic Link: (was: OVIRT-400) > Gerrit patches can reach CQ out-of-order > ---------------------------------------- > > Key: OVIRT-1759 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1759 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Change Queue, Gerrit/git > Reporter: Barak Korren > Assignee: infra > Priority: High > Labels: change-queue, gerrit > > Is seems that despite the fact that all the jobs involved were designed to preserve proper patch ordering, there can be cases where patches trigger Jenkins jobs in the wrong order, which in turn end up putting the patches in the wrong order into the CQ. This in turn, causes the CQ to fail accurately detecting the patches that cause issues. > Here is en example of such an occurance. The following patches were merged in the order specified below: > # https://gerrit.ovirt.org/c/83917 > # https://gerrit.ovirt.org/c/83918 > # https://gerrit.ovirt.org/c/83919 > # https://gerrit.ovirt.org/c/83920 > The standard-enqueue runs putting them in the CQ however, seem to have run in a different order: > # http://jenkins.ovirt.org/job/standard-enqueue/6712/ (83917) > # http://jenkins.ovirt.org/job/standard-enqueue/6713/ (83919) > # http://jenkins.ovirt.org/job/standard-enqueue/6714/ (83920) > # http://jenkins.ovirt.org/job/standard-enqueue/6715/ (83918) > This resulted in CQ 'add' command running in the wrong order: > # http://jenkins.ovirt.org/job/ovirt-master_change-queue/12200/ (add 83917) > # http://jenkins.ovirt.org/job/ovirt-master_change-queue/12201/ (add 83919) > # http://jenkins.ovirt.org/job/ovirt-master_change-queue/12202/ (add 83920) > # http://jenkins.ovirt.org/job/ovirt-master_change-queue/12203/ (add 83918) > We need to come up with a way to make the system properly preserver order. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years, 6 months

1
0
0 / 0

[JIRA] (OVIRT-1759) Gerrit patches can reach CQ out-of-order

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1759?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1759: -------------------------------- Epic Link: (was: OVIRT-400) > Gerrit patches can reach CQ out-of-order > ---------------------------------------- > > Key: OVIRT-1759 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1759 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Change Queue, Gerrit/git > Reporter: Barak Korren > Assignee: infra > Priority: High > Labels: change-queue, gerrit > > Is seems that despite the fact that all the jobs involved were designed to preserve proper patch ordering, there can be cases where patches trigger Jenkins jobs in the wrong order, which in turn end up putting the patches in the wrong order into the CQ. This in turn, causes the CQ to fail accurately detecting the patches that cause issues. > Here is en example of such an occurance. The following patches were merged in the order specified below: > # https://gerrit.ovirt.org/c/83917 > # https://gerrit.ovirt.org/c/83918 > # https://gerrit.ovirt.org/c/83919 > # https://gerrit.ovirt.org/c/83920 > The standard-enqueue runs putting them in the CQ however, seem to have run in a different order: > # http://jenkins.ovirt.org/job/standard-enqueue/6712/ (83917) > # http://jenkins.ovirt.org/job/standard-enqueue/6713/ (83919) > # http://jenkins.ovirt.org/job/standard-enqueue/6714/ (83920) > # http://jenkins.ovirt.org/job/standard-enqueue/6715/ (83918) > This resulted in CQ 'add' command running in the wrong order: > # http://jenkins.ovirt.org/job/ovirt-master_change-queue/12200/ (add 83917) > # http://jenkins.ovirt.org/job/ovirt-master_change-queue/12201/ (add 83919) > # http://jenkins.ovirt.org/job/ovirt-master_change-queue/12202/ (add 83920) > # http://jenkins.ovirt.org/job/ovirt-master_change-queue/12203/ (add 83918) > We need to come up with a way to make the system properly preserver order. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years, 6 months

1
0
0 / 0

[JIRA] (OVIRT-1774) Upstream source collector can fail to push on multi-branch projects

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1774?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1774: -------------------------------- Epic Link: (was: OVIRT-400) > Upstream source collector can fail to push on multi-branch projects > ------------------------------------------------------------------- > > Key: OVIRT-1774 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1774 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: pusher.py > Reporter: Barak Korren > Assignee: infra > Labels: poll-upstream-sources, upstream-source-collector > > When the upstream source collection code looks for similar patches in order to avoid pushing a new patch, it lookes for patches that contain the same change to the '{{upstream-sources.yaml}}' file, regardless of the branch they may belong to. > The code currently ignores the possibility that similar changes might be required for different branches, in which case different patches may need to be pushed. > The way of detecting similar patches should be changed so that either the branch name is included in the checksum that are used to identify a patch, or the query is limited to patches of the branch being handled. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

6 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Infra June 2018