- Infra - oVirt List Archives

[JIRA] (OVIRT-2194) Backup oVirt servers and services
by eyal edri (oVirt JIRA) 12 Jun '18

12 Jun '18

eyal edri created OVIRT-2194: -------------------------------- Summary: Backup oVirt servers and services Key: OVIRT-2194 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2194 Project: oVirt - virtualization made easy Issue Type: Epic Reporter: eyal edri Assignee: infra Priority: High -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1319) configure backup of stats.phx.ovirt.org
by eyal edri (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1319?page=com.atlassian.jira.… ] eyal edri updated OVIRT-1319: ----------------------------- Labels: backup phx (was: ) > configure backup of stats.phx.ovirt.org > --------------------------------------- > > Key: OVIRT-1319 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1319 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Evgheni Dereveanchin > Assignee: infra > Priority: Low > Labels: backup, phx > > The stats server is accumulating historical data, backups need to be set up so that we don't risk losing it. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1319) configure backup of stats.phx.ovirt.org
by eyal edri (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1319?page=com.atlassian.jira.… ] eyal edri updated OVIRT-1319: ----------------------------- Epic Link: (was: OVIRT-403) > configure backup of stats.phx.ovirt.org > --------------------------------------- > > Key: OVIRT-1319 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1319 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Evgheni Dereveanchin > Assignee: infra > Priority: Low > > The stats server is accumulating historical data, backups need to be set up so that we don't risk losing it. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1319) configure backup of stats.phx.ovirt.org
by eyal edri (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1319?page=com.atlassian.jira.… ] eyal edri updated OVIRT-1319: ----------------------------- Epic Link: (was: OVIRT-403) > configure backup of stats.phx.ovirt.org > --------------------------------------- > > Key: OVIRT-1319 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1319 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Evgheni Dereveanchin > Assignee: infra > Priority: Low > > The stats server is accumulating historical data, backups need to be set up so that we don't risk losing it. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1333) Exclude game/desktop packages from mirrors
by eyal edri (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1333?page=com.atlassian.jira.… ] eyal edri updated OVIRT-1333: ----------------------------- Labels: Icebox first_time_task (was: first_time_task) > Exclude game/desktop packages from mirrors > ------------------------------------------ > > Key: OVIRT-1333 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1333 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Repositories Mgmt > Reporter: Barak Korren > Assignee: infra > Labels: Icebox, first_time_task > > Our mirrors currently contain full copies of the CentOS and Fedora repos, including many large game and desktop productivity packages. > We should probably clean these packages from the repos to save space and bandwidth. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1333) Exclude game/desktop packages from mirrors
by eyal edri (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1333?page=com.atlassian.jira.… ] eyal edri updated OVIRT-1333: ----------------------------- Epic Link: (was: OVIRT-403) > Exclude game/desktop packages from mirrors > ------------------------------------------ > > Key: OVIRT-1333 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1333 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Repositories Mgmt > Reporter: Barak Korren > Assignee: infra > Labels: first_time_task > > Our mirrors currently contain full copies of the CentOS and Fedora repos, including many large game and desktop productivity packages. > We should probably clean these packages from the repos to save space and bandwidth. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1333) Exclude game/desktop packages from mirrors
by eyal edri (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1333?page=com.atlassian.jira.… ] eyal edri updated OVIRT-1333: ----------------------------- Epic Link: (was: OVIRT-403) > Exclude game/desktop packages from mirrors > ------------------------------------------ > > Key: OVIRT-1333 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1333 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Repositories Mgmt > Reporter: Barak Korren > Assignee: infra > Labels: first_time_task > > Our mirrors currently contain full copies of the CentOS and Fedora repos, including many large game and desktop productivity packages. > We should probably clean these packages from the repos to save space and bandwidth. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1877) Update docs to indicated adding 'jenkins:' prefix to build URLs
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1877?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1877: -------------------------------- Epic Link: (was: OVIRT-400) > Update docs to indicated adding 'jenkins:' prefix to build URLs > --------------------------------------------------------------- > > Key: OVIRT-1877 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1877 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Documentation > Reporter: Barak Korren > Assignee: infra > > Our infra includes multipile places where users can input text that is used as configuration for repoman. Users are typically expected to place URLs of build jobs there to make repoman acquire built artifacts (For e.g. testing). > So far documentation specified that the plain URL to the build job can be used. This turns out to only be true for builds made on jenkins.ovirt.org. For URLs pointing at other jenkins servers, the '{{jenkins:}}' prefix needs to be added. > Documentation should be updated to teach users to add the '{{jenkins:}}' prefix. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1877) Update docs to indicated adding 'jenkins:' prefix to build URLs
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1877?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1877: -------------------------------- Epic Link: (was: OVIRT-400) > Update docs to indicated adding 'jenkins:' prefix to build URLs > --------------------------------------------------------------- > > Key: OVIRT-1877 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1877 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Documentation > Reporter: Barak Korren > Assignee: infra > > Our infra includes multipile places where users can input text that is used as configuration for repoman. Users are typically expected to place URLs of build jobs there to make repoman acquire built artifacts (For e.g. testing). > So far documentation specified that the plain URL to the build job can be used. This turns out to only be true for builds made on jenkins.ovirt.org. For URLs pointing at other jenkins servers, the '{{jenkins:}}' prefix needs to be added. > Documentation should be updated to teach users to add the '{{jenkins:}}' prefix. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1878) GitHub support for pusher.py
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1878?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1878: -------------------------------- Epic Link: (was: OVIRT-400) > GitHub support for pusher.py > ---------------------------- > > Key: OVIRT-1878 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1878 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: pusher.py > Reporter: Barak Korren > Assignee: infra > Labels: first_time_task, github > > '{{pusher.py}}' currently only supports gerrit, what this means in practice is that automated polling for upstream source changes is only available for repos that are hosted in Gerrit. > We need to support this in GitHub as well. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1878) GitHub support for pusher.py
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1878?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1878: -------------------------------- Epic Link: (was: OVIRT-400) > GitHub support for pusher.py > ---------------------------- > > Key: OVIRT-1878 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1878 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: pusher.py > Reporter: Barak Korren > Assignee: infra > Labels: first_time_task, github > > '{{pusher.py}}' currently only supports gerrit, what this means in practice is that automated polling for upstream source changes is only available for repos that are hosted in Gerrit. > We need to support this in GitHub as well. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1885) Remove slave/resource management from Jenkins
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1885?page=com.atlassian.jira.… ] Barak Korren reassigned OVIRT-1885: ----------------------------------- Assignee: (was: infra) > Remove slave/resource management from Jenkins > --------------------------------------------- > > Key: OVIRT-1885 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1885 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins Master, Jenkins Slaves > Reporter: Barak Korren > Labels: scale > > The way out infra is configure right now, resource allocation and management is done by Jenkins itself. This means that all resources need to pre-allocated to Jenkins in the form of slaves. > If we want to have separate Jenkins masters, our current configuration will force us to hard-split the resources between different Jenkins masters. > If we want to share our pool of resources between multiple masters, it means that resource allocation needs to move out of Jenkins to external tools. > Potential tools for different types of resources are: > * Beaker for managing physical hosts > * oVirt + a Jenkins could provider plugin for managing VMs > * OpenShift for managing containers (As a replacement for chroots). -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1885) Remove slave/resource management from Jenkins
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1885?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1885: -------------------------------- Epic Link: (was: OVIRT-400) > Remove slave/resource management from Jenkins > --------------------------------------------- > > Key: OVIRT-1885 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1885 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins Master, Jenkins Slaves > Reporter: Barak Korren > Assignee: infra > Labels: scale > > The way out infra is configure right now, resource allocation and management is done by Jenkins itself. This means that all resources need to pre-allocated to Jenkins in the form of slaves. > If we want to have separate Jenkins masters, our current configuration will force us to hard-split the resources between different Jenkins masters. > If we want to share our pool of resources between multiple masters, it means that resource allocation needs to move out of Jenkins to external tools. > Potential tools for different types of resources are: > * Beaker for managing physical hosts > * oVirt + a Jenkins could provider plugin for managing VMs > * OpenShift for managing containers (As a replacement for chroots). -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1885) Remove slave/resource management from Jenkins
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1885?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1885: -------------------------------- Epic Link: (was: OVIRT-400) > Remove slave/resource management from Jenkins > --------------------------------------------- > > Key: OVIRT-1885 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1885 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins Master, Jenkins Slaves > Reporter: Barak Korren > Assignee: infra > Labels: scale > > The way out infra is configure right now, resource allocation and management is done by Jenkins itself. This means that all resources need to pre-allocated to Jenkins in the form of slaves. > If we want to have separate Jenkins masters, our current configuration will force us to hard-split the resources between different Jenkins masters. > If we want to share our pool of resources between multiple masters, it means that resource allocation needs to move out of Jenkins to external tools. > Potential tools for different types of resources are: > * Beaker for managing physical hosts > * oVirt + a Jenkins could provider plugin for managing VMs > * OpenShift for managing containers (As a replacement for chroots). -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1615) Replace Artifactory with Nexus
by eyal edri (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1615?page=com.atlassian.jira.… ] eyal edri updated OVIRT-1615: ----------------------------- Epic Link: (was: OVIRT-403) > Replace Artifactory with Nexus > ------------------------------ > > Key: OVIRT-1615 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1615 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: General > Reporter: Barak Korren > Assignee: infra > Priority: Lowest > Labels: Icebox > > Nexus is the main competitor to Artifactory. It has similar features. Lokking at documentation available about it, it looks like the open source version of it supports a much bigger feature set the Artifactory without requiring an upgrade to a payed version: > https://help.sonatype.com/display/NXRM3/Repository+Manager+Feature+Matrix > Of interest to us are the PyPi (Python) support, the NPM (Javascript) and the Docker support. > It seems that Nexus is available as a container, so we may try deploying it on OpenShift. > I think we need to plan and execute a migration to Nexus. > This ticket should server as a tracking ticket for the entire work. We will create blocker tickets to track needed steps. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1615) Replace Artifactory with Nexus
by eyal edri (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1615?page=com.atlassian.jira.… ] eyal edri updated OVIRT-1615: ----------------------------- Epic Link: (was: OVIRT-403) > Replace Artifactory with Nexus > ------------------------------ > > Key: OVIRT-1615 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1615 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: General > Reporter: Barak Korren > Assignee: infra > Priority: Lowest > Labels: Icebox > > Nexus is the main competitor to Artifactory. It has similar features. Lokking at documentation available about it, it looks like the open source version of it supports a much bigger feature set the Artifactory without requiring an upgrade to a payed version: > https://help.sonatype.com/display/NXRM3/Repository+Manager+Feature+Matrix > Of interest to us are the PyPi (Python) support, the NPM (Javascript) and the Docker support. > It seems that Nexus is available as a container, so we may try deploying it on OpenShift. > I think we need to plan and execute a migration to Nexus. > This ticket should server as a tracking ticket for the entire work. We will create blocker tickets to track needed steps. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1615) Replace Artifactory with Nexus
by eyal edri (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1615?page=com.atlassian.jira.… ] eyal edri updated OVIRT-1615: ----------------------------- Labels: Icebox (was: ) > Replace Artifactory with Nexus > ------------------------------ > > Key: OVIRT-1615 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1615 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: General > Reporter: Barak Korren > Assignee: infra > Priority: Lowest > Labels: Icebox > > Nexus is the main competitor to Artifactory. It has similar features. Lokking at documentation available about it, it looks like the open source version of it supports a much bigger feature set the Artifactory without requiring an upgrade to a payed version: > https://help.sonatype.com/display/NXRM3/Repository+Manager+Feature+Matrix > Of interest to us are the PyPi (Python) support, the NPM (Javascript) and the Docker support. > It seems that Nexus is available as a container, so we may try deploying it on OpenShift. > I think we need to plan and execute a migration to Nexus. > This ticket should server as a tracking ticket for the entire work. We will create blocker tickets to track needed steps. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1920) Modify ci_env_client.py to be case and signs insensitive
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1920?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1920: -------------------------------- Epic Link: (was: OVIRT-400) > Modify ci_env_client.py to be case and signs insensitive > -------------------------------------------------------- > > Key: OVIRT-1920 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1920 > Project: oVirt - virtualization made easy > Issue Type: Task > Components: mock_runner > Reporter: Daniel Belenky > Assignee: infra > > In OVIRT-1892 we make stdci config be case and signs insensitive. It means that when we will write a runner (or modify mock_runner) to use the new config, ci_env_client will have to deal with a normalized structure (without cases nor signs as dots and dashes). -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1920) Modify ci_env_client.py to be case and signs insensitive
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1920?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1920: -------------------------------- Epic Link: (was: OVIRT-400) > Modify ci_env_client.py to be case and signs insensitive > -------------------------------------------------------- > > Key: OVIRT-1920 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1920 > Project: oVirt - virtualization made easy > Issue Type: Task > Components: mock_runner > Reporter: Daniel Belenky > Assignee: infra > > In OVIRT-1892 we make stdci config be case and signs insensitive. It means that when we will write a runner (or modify mock_runner) to use the new config, ci_env_client will have to deal with a normalized structure (without cases nor signs as dots and dashes). -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1920) Modify ci_env_client.py to be case and signs insensitive
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1920?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1920: -------------------------------- Component/s: (was: STDCI DSL) (was: Standard CI (Pipelines)) mock_runner > Modify ci_env_client.py to be case and signs insensitive > -------------------------------------------------------- > > Key: OVIRT-1920 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1920 > Project: oVirt - virtualization made easy > Issue Type: Task > Components: mock_runner > Reporter: Daniel Belenky > Assignee: infra > > In OVIRT-1892 we make stdci config be case and signs insensitive. It means that when we will write a runner (or modify mock_runner) to use the new config, ci_env_client will have to deal with a normalized structure (without cases nor signs as dots and dashes). -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1945) Allow to keep running containers in docker_cleanup
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1945?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1945: -------------------------------- Epic Link: (was: OVIRT-400) > Allow to keep running containers in docker_cleanup > -------------------------------------------------- > > Key: OVIRT-1945 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1945 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: oVirt CI, Standard CI (Freestyle), Standard CI (Pipelines) > Reporter: Daniel Belenky > Assignee: infra > Labels: standard-ci > > docker_cleanup.py stops all running containers before it removes the images. > We should make it optional as well as allow whitelisting containers. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1945) Allow to keep running containers in docker_cleanup
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1945?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1945: -------------------------------- Epic Link: (was: OVIRT-400) > Allow to keep running containers in docker_cleanup > -------------------------------------------------- > > Key: OVIRT-1945 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1945 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: oVirt CI, Standard CI (Freestyle), Standard CI (Pipelines) > Reporter: Daniel Belenky > Assignee: infra > Labels: standard-ci > > docker_cleanup.py stops all running containers before it removes the images. > We should make it optional as well as allow whitelisting containers. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1953) Add PPC mirrors
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1953?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1953: -------------------------------- Resolution: Duplicate Status: Done (was: To Do) Closing as duplicate of OVIRT-2041 > Add PPC mirrors > --------------- > > Key: OVIRT-1953 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1953 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: CI Mirrors > Reporter: Daniel Belenky > Assignee: infra > -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1953) Add PPC mirrors
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1953?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1953: -------------------------------- Epic Link: (was: OVIRT-400) > Add PPC mirrors > --------------- > > Key: OVIRT-1953 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1953 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: CI Mirrors > Reporter: Daniel Belenky > Assignee: infra > -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1953) Add PPC mirrors
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1953?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1953: -------------------------------- Epic Link: (was: OVIRT-400) > Add PPC mirrors > --------------- > > Key: OVIRT-1953 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1953 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: CI Mirrors > Reporter: Daniel Belenky > Assignee: infra > -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1958) Allow custom checkout dir
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1958?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-1958: ------------------------------------- [~dbelenky(a)redhat.com] I think we fixed this already no? there is no patch attached... > Allow custom checkout dir > ------------------------- > > Key: OVIRT-1958 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1958 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Daniel Belenky > Assignee: infra > > Currently, we assume that the checkout dir has the same name as the project. This should be configurable by environment variable passed from JJB. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1958) Allow custom checkout dir
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1958?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1958: -------------------------------- Epic Link: (was: OVIRT-400) > Allow custom checkout dir > ------------------------- > > Key: OVIRT-1958 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1958 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Daniel Belenky > Assignee: infra > > Currently, we assume that the checkout dir has the same name as the project. This should be configurable by environment variable passed from JJB. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1958) Allow custom checkout dir
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1958?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1958: -------------------------------- Epic Link: (was: OVIRT-400) > Allow custom checkout dir > ------------------------- > > Key: OVIRT-1958 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1958 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Daniel Belenky > Assignee: infra > > Currently, we assume that the checkout dir has the same name as the project. This should be configurable by environment variable passed from JJB. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1959) Make usrc.py support Git tags
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1959?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1959: -------------------------------- Epic Link: OVIRT-1124 (was: OVIRT-400) > Make usrc.py support Git tags > ----------------------------- > > Key: OVIRT-1959 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1959 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: usrc.py > Reporter: Barak Korren > Assignee: infra > > There are multiple features that could be useful to add to {{usrc.py}} that has to do with Git tags: > # *Snap to tag* - when running {{update}} take the latest tagged commit from the branch instead of the latest commit. This could further be enhanced to decide what to do when there is no tagged commit that is newer then what we already have - we can either decide not to update or update to the latest (untagged) commit. > # *Copy tag* - when running with {{--commit}} and the upstream commit we're updating into is tagged, store some information somewhere so that if the commit is merged, the CI system could tag it automatically and push that tag. It should be possible to customise the tag we add to allow it to be different but derived from the upstream tag. One possible place to store the needed information is to use a header in the commit message like we do for auto-merge. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1959) Make usrc.py support Git tags
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1959?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1959: -------------------------------- Epic Link: OVIRT-1124 (was: OVIRT-400) > Make usrc.py support Git tags > ----------------------------- > > Key: OVIRT-1959 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1959 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: usrc.py > Reporter: Barak Korren > Assignee: infra > > There are multiple features that could be useful to add to {{usrc.py}} that has to do with Git tags: > # *Snap to tag* - when running {{update}} take the latest tagged commit from the branch instead of the latest commit. This could further be enhanced to decide what to do when there is no tagged commit that is newer then what we already have - we can either decide not to update or update to the latest (untagged) commit. > # *Copy tag* - when running with {{--commit}} and the upstream commit we're updating into is tagged, store some information somewhere so that if the commit is merged, the CI system could tag it automatically and push that tag. It should be possible to customise the tag we add to allow it to be different but derived from the upstream tag. One possible place to store the needed information is to use a header in the commit message like we do for auto-merge. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1960) Make pusehr.py able to push Git tags
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1960?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1960: -------------------------------- Epic Link: (was: OVIRT-400) > Make pusehr.py able to push Git tags > ------------------------------------ > > Key: OVIRT-1960 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1960 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: pusher.py > Reporter: Barak Korren > Assignee: infra > > {{pusher.py}} knows how to push patches into remote SCMs. WE should also add functionality for pushing tags. More specifically: > # It should be possible to request that and arbitrary tag for HEAD be created and pushed. This should make it possible to implement OVIRT-1717 > # It should be possible to create and push a tag with information that is gathered and created by {{usrc.py}}. This is a counterpart to OVIRT-1959 -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1960) Make pusehr.py able to push Git tags
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1960?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1960: -------------------------------- Epic Link: (was: OVIRT-400) > Make pusehr.py able to push Git tags > ------------------------------------ > > Key: OVIRT-1960 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1960 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: pusher.py > Reporter: Barak Korren > Assignee: infra > > {{pusher.py}} knows how to push patches into remote SCMs. WE should also add functionality for pushing tags. More specifically: > # It should be possible to request that and arbitrary tag for HEAD be created and pushed. This should make it possible to implement OVIRT-1717 > # It should be possible to create and push a tag with information that is gathered and created by {{usrc.py}}. This is a counterpart to OVIRT-1959 -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1963) Nicer UI for OST manual job
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1963?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1963: -------------------------------- Epic Link: OVIRT-2185 (was: OVIRT-400) > Nicer UI for OST manual job > ---------------------------- > > Key: OVIRT-1963 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1963 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: OST Manual job > Reporter: Barak Korren > Assignee: infra > Labels: first_time_task > > Make the following details shown in the builds list of the OST manual job so that finding a particular build in the builds list is easier: > # The person who triggered the build > # The suit that was run > # The amount of URLs passed into extra-sources, and if possible - the name of the project whose modified packages were included. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1963) Nicer UI for OST manual job
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1963?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1963: -------------------------------- Epic Link: OVIRT-2185 (was: OVIRT-400) > Nicer UI for OST manual job > ---------------------------- > > Key: OVIRT-1963 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1963 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: OST Manual job > Reporter: Barak Korren > Assignee: infra > Labels: first_time_task > > Make the following details shown in the builds list of the OST manual job so that finding a particular build in the builds list is easier: > # The person who triggered the build > # The suit that was run > # The amount of URLs passed into extra-sources, and if possible - the name of the project whose modified packages were included. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1965) Add failure details to CQ messages
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1965?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1965: -------------------------------- Epic Link: OVIRT-2185 (was: OVIRT-400) > Add failure details to CQ messages > ---------------------------------- > > Key: OVIRT-1965 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1965 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Change Queue > Reporter: Barak Korren > Assignee: infra > > In order to streamline the process for debugging CQ issues, we should have more failure details added to the messages it sends. Those details should include: > # The names of the OST suits that failed > # The OST tests that failed > # If it was a build failure rather then an OST failure > # If it was possible to detect - the particular change(s) that caused failure. > #if its possible to tell - if its an infra issue or a code regression > To implement this we would need at the very least a richer interface for passing information between the CQ tester and the and manager jobs - possibly some kind of a structured data file passed around. We may also need a richer interface to OST itself (to tell which test failed) and perhaps even to the build jobs (to tell why the build failed). -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1965) Add failure details to CQ messages
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1965?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1965: -------------------------------- Epic Link: OVIRT-2185 (was: OVIRT-400) > Add failure details to CQ messages > ---------------------------------- > > Key: OVIRT-1965 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1965 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Change Queue > Reporter: Barak Korren > Assignee: infra > > In order to streamline the process for debugging CQ issues, we should have more failure details added to the messages it sends. Those details should include: > # The names of the OST suits that failed > # The OST tests that failed > # If it was a build failure rather then an OST failure > # If it was possible to detect - the particular change(s) that caused failure. > #if its possible to tell - if its an infra issue or a code regression > To implement this we would need at the very least a richer interface for passing information between the CQ tester and the and manager jobs - possibly some kind of a structured data file passed around. We may also need a richer interface to OST itself (to tell which test failed) and perhaps even to the build jobs (to tell why the build failed). -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1973) vdsm_master_check-patch-fc27 fail due to yum repo issues
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1973?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1973: -------------------------------- Issue Type: Outage (was: By-EMAIL) > vdsm_master_check-patch-fc27 fail due to yum repo issues > -------------------------------------------------------- > > Key: OVIRT-1973 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1973 > Project: oVirt - virtualization made easy > Issue Type: Outage > Components: CI client projects > Reporter: danken > Assignee: infra > > Once in a while, jobs are failing due to > [MIRROR] kmod-kvdo-6.1.1.24-1.fc27.x86_64.rpm: Downloading successful, > but checksum doesn't match. Calculated: > 54996f8e7877b533bf43825853cd3c7cfd0f7df5cb6a1876e50c9ade7829dd73(sha256) > Expected: 7a8294588764bd2c14adaa7d24218cce344930c1ce62a24b17208d1cd629c461(sha256) > for example > http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-x86_64/2830/conso… -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1973) vdsm_master_check-patch-fc27 fail due to yum repo issues
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1973?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1973: -------------------------------- Epic Link: (was: OVIRT-400) > vdsm_master_check-patch-fc27 fail due to yum repo issues > -------------------------------------------------------- > > Key: OVIRT-1973 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1973 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Components: CI client projects > Reporter: danken > Assignee: infra > > Once in a while, jobs are failing due to > [MIRROR] kmod-kvdo-6.1.1.24-1.fc27.x86_64.rpm: Downloading successful, > but checksum doesn't match. Calculated: > 54996f8e7877b533bf43825853cd3c7cfd0f7df5cb6a1876e50c9ade7829dd73(sha256) > Expected: 7a8294588764bd2c14adaa7d24218cce344930c1ce62a24b17208d1cd629c461(sha256) > for example > http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-x86_64/2830/conso… -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1973) vdsm_master_check-patch-fc27 fail due to yum repo issues
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1973?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1973: -------------------------------- Epic Link: (was: OVIRT-400) > vdsm_master_check-patch-fc27 fail due to yum repo issues > -------------------------------------------------------- > > Key: OVIRT-1973 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1973 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Components: CI client projects > Reporter: danken > Assignee: infra > > Once in a while, jobs are failing due to > [MIRROR] kmod-kvdo-6.1.1.24-1.fc27.x86_64.rpm: Downloading successful, > but checksum doesn't match. Calculated: > 54996f8e7877b533bf43825853cd3c7cfd0f7df5cb6a1876e50c9ade7829dd73(sha256) > Expected: 7a8294588764bd2c14adaa7d24218cce344930c1ce62a24b17208d1cd629c461(sha256) > for example > http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-x86_64/2830/conso… -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1983) Switch to using JJB >= 2.0.6
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1983?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1983: -------------------------------- Epic Link: (was: OVIRT-400) > Switch to using JJB >= 2.0.6 > ---------------------------- > > Key: OVIRT-1983 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1983 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: JJB > Reporter: Barak Korren > Assignee: infra > > Version 2.0.6 is the latest released version of JJB at the time of this writing. We've been using a very old development version of JJB (1.4.1.dev50) for a long time and its about time we upgraded. Other then that the post 2.0.0 has one major feature which is Jinja2 support which may be very useful for us. > In order to upgrade, we probably need to implement OVIRT-1466 first. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1983) Switch to using JJB >= 2.0.6
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1983?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1983: -------------------------------- Epic Link: (was: OVIRT-400) > Switch to using JJB >= 2.0.6 > ---------------------------- > > Key: OVIRT-1983 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1983 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: JJB > Reporter: Barak Korren > Assignee: infra > > Version 2.0.6 is the latest released version of JJB at the time of this writing. We've been using a very old development version of JJB (1.4.1.dev50) for a long time and its about time we upgraded. Other then that the post 2.0.0 has one major feature which is Jinja2 support which may be very useful for us. > In order to upgrade, we probably need to implement OVIRT-1466 first. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1984) Create "out-of-band" slave cleanup and setup jobs
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1984?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1984: -------------------------------- Epic Link: OVIRT-2178 (was: OVIRT-400) > 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#100087)

1 0

[JIRA] (OVIRT-1984) Create "out-of-band" slave cleanup and setup jobs
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1984?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1984: -------------------------------- Epic Link: OVIRT-2178 (was: OVIRT-400) > 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#100087)

1 0

[JIRA] (OVIRT-1988) Add default behavior in secret_resolvers.py
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1988?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1988: -------------------------------- Labels: first_time_task (was: ) > Add default behavior in secret_resolvers.py > ------------------------------------------- > > Key: OVIRT-1988 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1988 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: mock_runner > Reporter: Daniel Belenky > Assignee: infra > Labels: first_time_task > > Currently, when users try to run CI locally (currently with mock_runner), > if their project has a secret dependency they have to either write a local > secrets file, or to temporary modify their environment.yaml. > The file format should have support for default behavior in case a secret > was not found. Maybe something similar to: > {code:java} > --- > - name: MY_SECRET > valueFrom: > secretKeyRef: > name: secret_name > key: key_from_secret > default: > from-env: ENV_VAR_NAME > # OR > value: default-value > {code} -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1988) Add default behavior in secret_resolvers.py
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1988?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1988: -------------------------------- Epic Link: (was: OVIRT-400) > Add default behavior in secret_resolvers.py > ------------------------------------------- > > Key: OVIRT-1988 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1988 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: mock_runner > Reporter: Daniel Belenky > Assignee: infra > > Currently, when users try to run CI locally (currently with mock_runner), > if their project has a secret dependency they have to either write a local > secrets file, or to temporary modify their environment.yaml. > The file format should have support for default behavior in case a secret > was not found. Maybe something similar to: > {code:java} > --- > - name: MY_SECRET > valueFrom: > secretKeyRef: > name: secret_name > key: key_from_secret > default: > from-env: ENV_VAR_NAME > # OR > value: default-value > {code} -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1988) Add default behavior in secret_resolvers.py
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1988?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1988: -------------------------------- Epic Link: (was: OVIRT-400) > Add default behavior in secret_resolvers.py > ------------------------------------------- > > Key: OVIRT-1988 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1988 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: mock_runner > Reporter: Daniel Belenky > Assignee: infra > > Currently, when users try to run CI locally (currently with mock_runner), > if their project has a secret dependency they have to either write a local > secrets file, or to temporary modify their environment.yaml. > The file format should have support for default behavior in case a secret > was not found. Maybe something similar to: > {code:java} > --- > - name: MY_SECRET > valueFrom: > secretKeyRef: > name: secret_name > key: key_from_secret > default: > from-env: ENV_VAR_NAME > # OR > value: default-value > {code} -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1991) jenkins triggers a build on a deleted branch
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1991?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1991: -------------------------------- Epic Link: (was: OVIRT-400) > jenkins triggers a build on a deleted branch > -------------------------------------------- > > Key: OVIRT-1991 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1991 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Standard CI (Pipelines) > Reporter: Roy Golan > Assignee: infra > Priority: Low > > I did some pruning, and removed old, unused branches, from > https://github.com/oVirt/ovirt-openshift-extensions. Now I suddenly see my > jenkins build is failing, because it triggered a build on the deleted > branch. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1991) jenkins triggers a build on a deleted branch
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1991?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1991: -------------------------------- Epic Link: (was: OVIRT-400) > jenkins triggers a build on a deleted branch > -------------------------------------------- > > Key: OVIRT-1991 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1991 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Standard CI (Pipelines) > Reporter: Roy Golan > Assignee: infra > Priority: Low > > I did some pruning, and removed old, unused branches, from > https://github.com/oVirt/ovirt-openshift-extensions. Now I suddenly see my > jenkins build is failing, because it triggered a build on the deleted > branch. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1996) Remove the 4.1 nightly publisher job
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1996?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1996: -------------------------------- Epic Link: OVIRT-2044 (was: OVIRT-400) > Remove the 4.1 nightly publisher job > ------------------------------------ > > Key: OVIRT-1996 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1996 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Publisher jobs > Reporter: Barak Korren > Assignee: infra > Labels: first_time_task > > It may be the case that we don't need the 4.1 publisher jobs any more. > Since those jobs are still in the old pre-CQ format where artifacts we collected by the job itself, their existence makes the CI system's maintenance harder... -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-1996) Remove the 4.1 nightly publisher job
by Barak Korren (oVirt JIRA) 12 Jun '18

12 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1996?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1996: -------------------------------- Epic Link: OVIRT-2044 (was: OVIRT-400) > Remove the 4.1 nightly publisher job > ------------------------------------ > > Key: OVIRT-1996 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1996 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Publisher jobs > Reporter: Barak Korren > Assignee: infra > Labels: first_time_task > > It may be the case that we don't need the 4.1 publisher jobs any more. > Since those jobs are still in the old pre-CQ format where artifacts we collected by the job itself, their existence makes the CI system's maintenance harder... -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0