July 2019 - Infra - Ovirt List Archives

[JIRA] (OVIRT-914) Better arch support for mock_runner.sh

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-914?page=com.atlassian.jira... ] Barak Korren updated OVIRT-914: ------------------------------- Resolution: Won't Fix Status: Done (was: To Do) well we have one place where this would have been useful (we have a custom packages file for s390x in the jenkins project). we managed to do without this so far because of the added flexibility v2 gave us. > Better arch support for mock_runner.sh > -------------------------------------- > > Key: OVIRT-914 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-914 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: mock_runner > Reporter: Barak Korren > Assignee: infra > Labels: mock_runner.sh, standard-ci > > We managed to us "{{mock_runner.sh}}" in multi-arch so far because it was flexible enough to allow us to select the chroot file. > The issue is that mock_runner does not actually *know* the arch we are running on so we can`t:: > * do different mounts per-arch > * install different packages per-arch > * have different {{check_*}} scripts per-arch -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100105)

5 years, 5 months

1
0
0 / 0

[JIRA] (OVIRT-1396) Add a new 'test-system-artifacts' Standard-CI stage

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1396?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1396: -------------------------------- Resolution: Won't Fix Status: Done (was: To Do) this was part of the ovirt-containers CI design, and a longer-term plan to enable properly handling node/appliance in the CQ. Since we're now working on gating to retire CQ, we're probably not gonna implement this > Add a new 'test-system-artifacts' Standard-CI stage > --------------------------------------------------- > > Key: OVIRT-1396 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1396 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Standard CI (Pipelines) > Reporter: Barak Korren > Assignee: infra > > This is a part of [containers CI/CD|https://docs.google.com/a/redhat.com/document/d/1mEo3E0kRvlUWT9VaSP...] flow implementation process. > An order to allow building and testing processes for containers to be triggered after package that are needed for them are built, we will introduce the "{{test-system-artifacts}}" standard-CI stage. > This stage will be invoked from the 'experimental' or 'change-queue-tester' pipelines jost like the existing OST-based flows. > In order to provide package and repo information to the std-CI script invoked by this stage we well need to implement OVIRT-1391 -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100105)

5 years, 5 months

1
0
0 / 0

Change in stage-stdci1[master]: Add gate-triggering Zuul job

by review＠gerrit-staging.phx.ovirt.org

From Barak Korren <bkorren(a)redhat.com>: Hello Jenkins CI, Zuul CI, I'd like you to reexamine a change. Please visit https://gerrit-staging.phx.ovirt.org/256 to look at the new patch set (#31). Change subject: Add gate-triggering Zuul job ...................................................................... Add gate-triggering Zuul job Change-Id: Ic2892757a81c5c0705bde6db77bdc546efe49faf Signed-off-by: Barak Korren <bkorren(a)redhat.com> --- M .zuul.yaml A automation/playbooks/trigger_gate_job.yaml 2 files changed, 68 insertions(+), 2 deletions(-) git pull ssh://gerrit-staging.phx.ovirt.org:29418/stage-stdci1 refs/changes/56/256/31 -- To view, visit https://gerrit-staging.phx.ovirt.org/256 To unsubscribe, visit https://gerrit-staging.phx.ovirt.org/settings Gerrit-Project: stage-stdci1 Gerrit-Branch: master Gerrit-MessageType: newpatchset Gerrit-Change-Id: Ic2892757a81c5c0705bde6db77bdc546efe49faf Gerrit-Change-Number: 256 Gerrit-PatchSet: 31 Gerrit-Owner: Barak Korren <bkorren(a)redhat.com> Gerrit-Reviewer: Barak Korren <bkorren(a)redhat.com> Gerrit-Reviewer: Jenkins CI <infra(a)ovirt.org> Gerrit-Reviewer: Zuul CI <zuul(a)ovirt.org>

5 years, 5 months

1
0
0 / 0

[JIRA] (OVIRT-2230) Checkout using prow as a GitHub triggering mechanism

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2230?page=com.atlassian.jir... ] Barak Korren updated OVIRT-2230: -------------------------------- Resolution: Won't Fix Status: Done (was: To Do) that was an attempt ot integrate Prow with stdci - but Kubevirt decided to go 100% prow > Checkout using prow as a GitHub triggering mechanism > ---------------------------------------------------- > > Key: OVIRT-2230 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2230 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Jenkins Master > Reporter: Barak Korren > Assignee: infra > > [Prow|https://github.com/kubernetes/test-infra/tree/master/prow] is the service that Kubernetes are using to trigger their CI on GitHub events. > We should inspect it and see if it would be useful for us to adopt it. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100105)

5 years, 5 months

1
0
0 / 0

[JIRA] (OVIRT-2342) Create a repo called ovirt-engine-config

by Eyal Edri (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2342?page=com.atlassian.jir... ] Eyal Edri commented on OVIRT-2342: ---------------------------------- What this needed in the end? I don’t see a repo created. > Create a repo called ovirt-engine-config > ----------------------------------------- > > Key: OVIRT-2342 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2342 > Project: oVirt - virtualization made easy > Issue Type: Task > Components: GitHub > Reporter: Tareq Alayan > Assignee: infra > > the repo will contain the ansible role representing the ovirt-engine-config utility -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100105)

5 years, 5 months

1
0
0 / 0

[JIRA] (OVIRT-2443) Make sure that big containers KubVirt CI uses are cached on hosts

by Eyal Edri (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2443?page=com.atlassian.jir... ] Eyal Edri commented on OVIRT-2443: ---------------------------------- [~dbelenky(a)redhat.com] [~gbenhaim(a)redhat.com] [~bkorren(a)redhat.com] any update on this? > Make sure that big containers KubVirt CI uses are cached on hosts > ----------------------------------------------------------------- > > Key: OVIRT-2443 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2443 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: CI client projects > Reporter: Barak Korren > Assignee: infra > > Make sure that big containers KubVirt CI uses are cached on hosts -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100105)

5 years, 5 months

1
0
0 / 0

[JIRA] (OVIRT-1984) Create "out-of-band" slave cleanup and setup jobs

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1984?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1984: -------------------------------- Resolution: Won't Fix Status: Done (was: To Do) > Create "out-of-band" slave cleanup and setup jobs > ------------------------------------------------- > > Key: OVIRT-1984 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1984 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Jenkins Slaves > Reporter: Barak Korren > Assignee: infra > > Right now, we run slave cleaup and setup steps as part or every single job we run. This has several shortcomings: > # It takes a long time from the point a user submitted a patch to the point his actual test or build code runs > # If slave setup or cleanup steps fail - they fail the whole job for the user > # If slave setup or cleanup steps fail - they can keep failing for many jobs until the CI team intervenes manually > # There is a "chicken and an egg" issue where some parts of the CI code have to run before the slave was properly cleaned up and configured. This makes if harder to add new slaves for the system. > Here is a suggested scheme to fix all this: > # Label all slaves that should be cleaned up automatically as 'cleanable'. This is mostly to prevent the jobs described here from operating on the master node. > # Have a "cleanup scheduler" job that finds all slaves labelled as "cleanable" but not as "dirty" or "clean", labels them as "dirty" and runs a cleanup job on them. > # Have a "cleanup" job that is triggered on particular slaves by the "cleanup scheduler" job, runs cleaup and setup steps on them and then labels them as "clean" and removes the "dirty" label. > # Have all other CI jobs only use slaves with the "clean" label. > Notes: > # The "dirty" label is there to make the "cleanup scheduler" job not trigger twice on the same slave before the"cleanup" job started cleaning it up. > # Since all slaves used by the real jobs will always be clean - there will no longer be a need to run cleanup steps in the real jobs, thus saving time. > # If cleanup steps fail - the cleanup job will fail and the slave will not be marked as "clean" so real jobs will never try to use it. > # To solve the "chicken and egg" issue, the cleanup job probably must be a FreeStyle jobs and all the cleanup and setup code must be embedded into it by JJB. This will probably require a newer version of JJB then what we have so setting OVIRT-1983 as a blocker. > # There is an issue of how to make CI for this - if cleanup and setup steps are removed from the normal STDCI jobs, they they will not be checked by the "check-patch" job of the "jenkins repo". Here is a suggested scheme to solve this: > ## Have a way to "loan" slaves from the production jenkins to other Jenkins instances - this could be done by having a job that starts up the Jenkins JNLP client and tells it to connect to another Jenkins master. > ## As part of the "check-patch" job for the 'jenkins' repo - start a Jenkins master in a container - attach some production slaves to it and have it run cleanup and setup steps on them -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100105)

5 years, 5 months

1
0
0 / 0

[JIRA] (OVIRT-2178) "Borrow" slaves from CentOS CI

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2178?page=com.atlassian.jir... ] Barak Korren updated OVIRT-2178: -------------------------------- Resolution: Won't Fix Status: Done (was: To Do) > "Borrow" slaves from CentOS CI > ------------------------------ > > Key: OVIRT-2178 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2178 > Project: oVirt - virtualization made easy > Issue Type: Epic > Reporter: Barak Korren > Assignee: infra > > [CentOS CI|https://wiki.centos.org/QaWiki/CI] is a generic shared platform for building CI service for Open Source projects. > Amount other things, CentOS CI makes physical and virtual hosts available for running CI processes via the [Duffy|http://wiki.centos.org/QaWiki/CI/Duffy] system. > We should make oVirt CI able to consume resources from CentOs CI to augment and someday replace the hardware resources available to oVirt CI. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100105)

5 years, 5 months

1
0
0 / 0

Change in stage-stdci1[master]: Add gate-triggering Zuul job

by review＠gerrit-staging.phx.ovirt.org

From Barak Korren <bkorren(a)redhat.com>: Hello Jenkins CI, Zuul CI, I'd like you to reexamine a change. Please visit https://gerrit-staging.phx.ovirt.org/256 to look at the new patch set (#30). Change subject: Add gate-triggering Zuul job ...................................................................... Add gate-triggering Zuul job Change-Id: Ic2892757a81c5c0705bde6db77bdc546efe49faf Signed-off-by: Barak Korren <bkorren(a)redhat.com> --- M .zuul.yaml A automation/playbooks/trigger_gate_job.yaml 2 files changed, 67 insertions(+), 2 deletions(-) git pull ssh://gerrit-staging.phx.ovirt.org:29418/stage-stdci1 refs/changes/56/256/30 -- To view, visit https://gerrit-staging.phx.ovirt.org/256 To unsubscribe, visit https://gerrit-staging.phx.ovirt.org/settings Gerrit-Project: stage-stdci1 Gerrit-Branch: master Gerrit-MessageType: newpatchset Gerrit-Change-Id: Ic2892757a81c5c0705bde6db77bdc546efe49faf Gerrit-Change-Number: 256 Gerrit-PatchSet: 30 Gerrit-Owner: Barak Korren <bkorren(a)redhat.com> Gerrit-Reviewer: Barak Korren <bkorren(a)redhat.com> Gerrit-Reviewer: Jenkins CI <infra(a)ovirt.org> Gerrit-Reviewer: Zuul CI <zuul(a)ovirt.org>

5 years, 5 months

1
0
0 / 0

[JIRA] (OVIRT-2230) Checkout using prow as a GitHub triggering mechanism

by Eyal Edri (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2230?page=com.atlassian.jir... ] Eyal Edri commented on OVIRT-2230: ---------------------------------- Since KubeVirt are doing it already, is there anything left to do on this ticket? I don’t expect oVirt to move to it. > Checkout using prow as a GitHub triggering mechanism > ---------------------------------------------------- > > Key: OVIRT-2230 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2230 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Jenkins Master > Reporter: Barak Korren > Assignee: infra > > [Prow|https://github.com/kubernetes/test-infra/tree/master/prow] is the service that Kubernetes are using to trigger their CI on GitHub events. > We should inspect it and see if it would be useful for us to adopt it. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100105)

5 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Infra July 2019