[JIRA] (OVIRT-1300) Jenkins jobs stuck on mock init/scrub
by Evgheni Dereveanchin (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1300?page=com.atlassian.jir... ]
Evgheni Dereveanchin reassigned OVIRT-1300:
-------------------------------------------
Assignee: Barak Korren (was: infra)
> Jenkins jobs stuck on mock init/scrub
> -------------------------------------
>
> Key: OVIRT-1300
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1300
> Project: oVirt - virtualization made easy
> Issue Type: Bug
> Reporter: Evgheni Dereveanchin
> Assignee: Barak Korren
> Priority: High
>
> There's several dozen check-patch jobs currently stuck on the Jenkins Master with the last line related to mock:
> 09:44:22 ========== Scrubbing chroot
> 09:44:22 mock \
> 09:44:22 --configdir="/home/jenkins/workspace/ovirt-engine_master_check-patch-el7-x86_64/ovirt-engine" \
> 09:44:22 --root="mocker-epel-7-x86_64.el7" \
> 09:44:22 --resultdir="./mock_logs.I6ufSyEH/mocker-epel-7-x86_64.el7.scrub" \
> 09:44:22 --scrub=chroot
> This needs to be fixed.
--
This message was sent by Atlassian JIRA
(v1000.883.0#100040)
7 years, 8 months
[JIRA] (OVIRT-1301) Add timeouts to mirror client
by Barak Korren (oVirt JIRA)
Barak Korren created OVIRT-1301:
-----------------------------------
Summary: Add timeouts to mirror client
Key: OVIRT-1301
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1301
Project: oVirt - virtualization made easy
Issue Type: Bug
Components: Repositories Mgmt
Reporter: Barak Korren
Assignee: infra
Priority: High
It seems that the mirror client can get stuck forever if the mirror server responds slowly, or not at all.
We need to ad a time out to fall back to not using the mirrors.
--
This message was sent by Atlassian JIRA
(v1000.883.0#100040)
7 years, 8 months
[JIRA] (OVIRT-1300) Jenkins jobs stuck on mock init/scrub
by Evgheni Dereveanchin (oVirt JIRA)
Evgheni Dereveanchin created OVIRT-1300:
-------------------------------------------
Summary: Jenkins jobs stuck on mock init/scrub
Key: OVIRT-1300
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1300
Project: oVirt - virtualization made easy
Issue Type: Bug
Reporter: Evgheni Dereveanchin
Assignee: infra
Priority: High
There's several dozen check-patch jobs currently stuck on the Jenkins Master with the last line related to mock:
09:44:22 ========== Scrubbing chroot
09:44:22 mock \
09:44:22 --configdir="/home/jenkins/workspace/ovirt-engine_master_check-patch-el7-x86_64/ovirt-engine" \
09:44:22 --root="mocker-epel-7-x86_64.el7" \
09:44:22 --resultdir="./mock_logs.I6ufSyEH/mocker-epel-7-x86_64.el7.scrub" \
09:44:22 --scrub=chroot
This needs to be fixed.
--
This message was sent by Atlassian JIRA
(v1000.883.0#100040)
7 years, 8 months
[JIRA] (OVIRT-1299) Please provide a koji (and if possible bodhi) instance for ovirt repositories
by Martin Sivak (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1299?page=com.atlassian.jir... ]
Martin Sivak edited comment on OVIRT-1299 at 4/5/17 1:00 PM:
-------------------------------------------------------------
Do not make this more complex than it has to be. A simple text or ini file (in ovirt specific repository, not in the project itself!) where the maintainer can say which build (a link to jenkins, copr, koji, github, ...) should go to which release is enough. The same for source tarball. Just let us provide a link (git hash url, gitweb export or github for example).
All your tooling like publishers or CI or anything else can then consume this configuration without forcing us to use a fixed tag or branch structure. The maintainer should be in control of the releases or platform, not the automation.
oVirt is a distribution of pieces and some pieces have slightly different development model. Even some core oVirt project use GitHub as the primary source now.
This has been discussed couple of times already, for example here http://lists.ovirt.org/pipermail/devel/2017-February/029439.html and here http://lists.ovirt.org/pipermail/devel/2017-January/029161.html
was (Author: msivak(a)redhat.com):
Do not make this more complex than it has to be. A simple text or ini file where the maintainer can say which build (a link to jenkins, copr, koji, github, ...) should go to which release is enough. The same for source tarball. Just let us provide a link (git hash url, gitweb export or github for example).
All your tooling like publishers or CI or anything else can then consume this configuration without forcing us to use a fixed tag or branch structure. The maintainer should be in control of the releases or platform, not the automation.
oVirt is a distribution of pieces and some pieces have slightly different development model. Even some core oVirt project use GitHub as the primary source now.
This has been discussed couple of times already, for example here http://lists.ovirt.org/pipermail/devel/2017-February/029439.html and here http://lists.ovirt.org/pipermail/devel/2017-January/029161.html
> Please provide a koji (and if possible bodhi) instance for ovirt repositories
> -----------------------------------------------------------------------------
>
> Key: OVIRT-1299
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1299
> Project: oVirt - virtualization made easy
> Issue Type: New Feature
> Components: Repositories Mgmt
> Reporter: sbonazzo
> Assignee: infra
>
> Some of the maintainers of oVirt project wants to have control on the builds going into the release repositories without 3rd party intervention on it.
> They would like to have a dist-git + koji like developer experience.
> A bodhi instance would help reviewing the package before it lands on repositories.
--
This message was sent by Atlassian JIRA
(v1000.883.0#100040)
7 years, 8 months
[JIRA] (OVIRT-1299) Please provide a koji (and if possible bodhi) instance for ovirt repositories
by Martin Sivak (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1299?page=com.atlassian.jir... ]
Martin Sivak commented on OVIRT-1299:
-------------------------------------
Do not make this more complex than it has to be. A simple text or ini file where the maintainer can say which build (a link to jenkins, copr, koji, github, ...) should go to which release is enough. The same for source tarball. Just let us provide a link (git hash url, gitweb export or github for example).
All your tooling like publishers or CI or anything else can then consume this configuration without forcing us to use a fixed tag or branch structure. The maintainer should be in control of the releases or platform, not the automation.
oVirt is a distribution of pieces and some pieces have slightly different development model. Even some core oVirt project use GitHub as the primary source now.
This has been discussed couple of times already, for example here http://lists.ovirt.org/pipermail/devel/2017-February/029439.html and here http://lists.ovirt.org/pipermail/devel/2017-January/029161.html
> Please provide a koji (and if possible bodhi) instance for ovirt repositories
> -----------------------------------------------------------------------------
>
> Key: OVIRT-1299
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1299
> Project: oVirt - virtualization made easy
> Issue Type: New Feature
> Components: Repositories Mgmt
> Reporter: sbonazzo
> Assignee: infra
>
> Some of the maintainers of oVirt project wants to have control on the builds going into the release repositories without 3rd party intervention on it.
> They would like to have a dist-git + koji like developer experience.
> A bodhi instance would help reviewing the package before it lands on repositories.
--
This message was sent by Atlassian JIRA
(v1000.883.0#100040)
7 years, 8 months
[JIRA] (OVIRT-1299) Please provide a koji (and if possible bodhi) instance for ovirt repositories
by sbonazzo (oVirt JIRA)
sbonazzo created OVIRT-1299:
-------------------------------
Summary: Please provide a koji (and if possible bodhi) instance for ovirt repositories
Key: OVIRT-1299
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1299
Project: oVirt - virtualization made easy
Issue Type: New Feature
Components: Repositories Mgmt
Reporter: sbonazzo
Assignee: infra
Some of the maintainers of oVirt project wants to have control on the builds going into the release repositories without 3rd party intervention on it.
They would like to have a dist-git + koji like developer experience.
A bodhi instance would help reviewing the package before it lands on repositories.
--
This message was sent by Atlassian JIRA
(v1000.883.0#100040)
7 years, 8 months