[JIRA] (OVIRT-873) Implement Standard-CI with containers

[Barak Korren (oVirt JIRA)]

Barak Korren created OVIRT-873:
--

 Summary: Implement Standard-CI with containers
 Key: OVIRT-873
 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-873
 Project: oVirt - virtualization made easy
  Issue Type: Task
  Components: General
Reporter: Barak Korren
Assignee: infra


oVirt's Standard-CI is currently implemented using mock, and this has worked 
well for us so far.
Changing the implementation to use containers will provide several benefits:

* Faster start-up times - Most container provides have some form of image 
layering and caching that will be faster as bringing up a basic OS image then 
installing it with yum like mock does.
* Broader OS support - mock can only run on the Red Hat family of operating 
systems, and can only emulate those operating systems. Most container providers 
can both run on and emulate a broader range of operating systems.
* Better isolation and cleanup - Mock only isolates the file system, containers 
can isolate the file system as well as the networking layer and the process 
space.

Depending on the container provider, we may gain additional benefits:

* Some container providers like Kubernetes, can manage distributed compute 
resources across many nodes. This means can can stop managing Jenkins slaves 
and instead just have the Jenkins master start up containers on the provider.
* Some providers like OpenShift have built-in CI processes for creating and 
testing container images.

*Note:* At some point, David started an effort going this way: 
https://gerrit.ovirt.org/#/c/54376/




--
This message was sent by Atlassian JIRA
(v1000.571.2#100021)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-873) Implement Standard-CI with containers

[Barak Korren (oVirt JIRA)]

 [ 
https://ovirt-jira.atlassian.net/browse/OVIRT-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Barak Korren updated OVIRT-873:
---
Epic Link: OVIRT-403

> Implement Standard-CI with containers
> -
>
> Key: OVIRT-873
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-873
> Project: oVirt - virtualization made easy
>  Issue Type: Task
>  Components: General
>Reporter: Barak Korren
>Assignee: infra
>
> oVirt's Standard-CI is currently implemented using mock, and this has worked 
> well for us so far.
> Changing the implementation to use containers will provide several benefits:
> * Faster start-up times - Most container provides have some form of image 
> layering and caching that will be faster as bringing up a basic OS image then 
> installing it with yum like mock does.
> * Broader OS support - mock can only run on the Red Hat family of operating 
> systems, and can only emulate those operating systems. Most container 
> providers can both run on and emulate a broader range of operating systems.
> * Better isolation and cleanup - Mock only isolates the file system, 
> containers can isolate the file system as well as the networking layer and 
> the process space.
> Depending on the container provider, we may gain additional benefits:
> * Some container providers like Kubernetes, can manage distributed compute 
> resources across many nodes. This means can can stop managing Jenkins slaves 
> and instead just have the Jenkins master start up containers on the provider.
> * Some providers like OpenShift have built-in CI processes for creating and 
> testing container images.
> *Note:* At some point, David started an effort going this way: 
> https://gerrit.ovirt.org/#/c/54376/



--
This message was sent by Atlassian JIRA
(v1000.571.2#100021)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3718 - SUCCESS!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3718/,
Build Number: 3718,
Build Status: SUCCESS___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3717 - FAILURE!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3717/,
Build Number: 3717,
Build Status: FAILURE___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

oVirt infra daily report - unstable production jobs - 151

[jenkins]

Good morning!

Attached is the HTML page with the jenkins status report. You can see it also 
here:
 - 
http://jenkins.ovirt.org/job/system_jenkins-report/151//artifact/exported-artifacts/upstream_report.html

Cheers,
Jenkins


upstream_report.html
Description: Binary data
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [ovirt-devel] Gerrit headers are not added to commits in vdsm repo

[Nir Soffer]

On Sun, Nov 27, 2016 at 4:34 PM, Barak Korren  wrote:
> On 25 November 2016 at 16:57, Nir Soffer  wrote:
>> On Fri, Nov 25, 2016 at 4:45 PM, Tomáš Golembiovský  
>> wrote:
>>> Hi,
>>>
>>> I've noticed that in vdsm repo the merged commits do not contain the
>>> info headers added by Gerrit any more (Reviewed-by/Reviewed-on/etc.).
>>>
>>> Is that intentional? If yes, what was the motivation behind this?
>>>
>>> The change seem to have happened about 4 days ago. Sometime between the
>>> following two commits:
>>>
>>> * 505f5da  API: Introduce getQemuImageInfo API. [Maor Lipchuk]
>>> * 1c4a39c  protocoldetector: Avoid unneeded getpeername() [Nir Soffer]
>>
>> We switched vdsm to fast-forward 4 days ago, maybe this was unintended
>> side effect of this change?
>>
>> The gerrit headers are very useful, please add back.
>>
>
> Headers cannot be added in fast-forward mode b/c then you end up with
> a new commit hash - not fast forwarding to an existing commit.
>
> In other words - headers are only added when Gerrit creates a new
> commit - which in FF mode it never does.

Makes sense.

> I could move the project to "Rebase Always" which is like "Rebase if
> Necessary" but always creates a new commit (with headers). Please note
> that this is less strict then ff-only and therefore would lead to
> merged combinations that do not get tested in CI.

Or we can add this url before posting a patch (using commit hook):

https://gerrit.ovirt.org/#/q/change:I71a2ae262482edc8acf303f18eac6f9035e710bc

Also works for truncated change id:
https://gerrit.ovirt.org/#/q/change:I71a2ae262482edc

This will show also the backports for a change, even more useful.

Nir
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-869) Investigate proxy errors from proxy.phx.ovirt.org

[Gil Shinar (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23312#comment-23312
 ] 

Gil Shinar commented on OVIRT-869:
--

In the log I'm seeing the following error messages:
*ConnectionError: HTTPConnectionPool(host='ftp.linux.ncsu.edu', port=80): Max 
retries exceeded with url: /pub/fedora/linux/updates/23/x86_64/// (Caused by 
: [Errno 110] Connection timed out)
ConnectionError: HTTPConnectionPool(host='mirror.evolvedservers.com', port=80): 
Max retries exceeded with url: /CentOS/7.1.1503/os/x86_64//repodata/repomd.xml 
(Caused by : [Errno 113] No route to host)*

and
*ConnectionError: HTTPConnectionPool(host='mirror.evolvedservers.com', 
port=80): Max retries exceeded with url: 
/CentOS/7.1.1503/os/x86_64//repodata/repomd.xml (Caused by : [Errno 101] Network is unreachable)*

This one as well:
*ConnectionError: HTTPConnectionPool(host='mirror.symnds.com', port=80): Max 
retries exceeded with url: /CentOS/7.2.1511/os/x86_64//repodata/repomd.xml 
(Caused by : '')*

After restart looks like they have gone but we need to find the core of the 
problem

> Investigate proxy errors from proxy.phx.ovirt.org
> -
>
> Key: OVIRT-869
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-869
> Project: oVirt - virtualization made easy
>  Issue Type: Bug
>Reporter: eyal edri [Administrator]
>Assignee: infra
>Priority: Highest
>
> We need to make sure jobs don't fail on proxy like [1].
> Either use original repos if proxy is down or add watchdog / alerts for the 
> proxy service.
> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3693/artifact/exported-artifacts/basic_suite_master.sh-el7/logs/mocker-epel-7-x86_64.el7.init/root.log



--
This message was sent by Atlassian JIRA
(v1000.571.2#100021)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-871) unrelated CI failure

[Gil Shinar (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23311#comment-23311
 ] 

Gil Shinar commented on OVIRT-871:
--

We had an Artifactory issue.
Now looks like it is back to normal

> unrelated CI failure
> 
>
> Key: OVIRT-871
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-871
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: danken
>Assignee: infra
>
> Change https://gerrit.ovirt.org/#/c/67101/ just failed on
> http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch-fc24-x86_64/8031/consoleText
> which I believe is utterly unrelated to the patch. please resolved the 
> underlying problem.
> [ERROR] Failed to execute goal on project restapi-definition: Could not 
> resolve dependencies for project 
> org.ovirt.engine.api:restapi-definition:jar:4.1.0-SNAPSHOT: Failed to collect 
> dependencies at org.ovirt.engine.api:metamodel-runtime:jar:1.1.8: Failed to 
> read artifact descriptor for 
> org.ovirt.engine.api:metamodel-runtime:jar:1.1.8: Could not transfer artifact 
> org.ovirt.engine.api:metamodel-runtime:pom:1.1.8 from/to 
> ovirt-maven-repository 
> (http://artifactory.ovirt.org/artifactory/ovirt-mirror): Failed to transfer 
> file: 
> http://artifactory.ovirt.org/artifactory/ovirt-mirror/org/ovirt/engine/api/metamodel-runtime/1.1.8/metamodel-runtime-1.1.8.pom.
>  Return code is: 502 , ReasonPhrase:Proxy Error. -> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> [ERROR] 
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]   mvn  -rf :restapi-definition
> Makefile:256: recipe for target 'maven' failed
> make[1]: *** [maven] Error 1
> make[1]: Leaving directory 
> '/home/jenkins/workspace/ovirt-engine_master_check-patch-fc24-x86_64/ovirt-engine/rpmbuild/BUILD/ovirt-engine-4.1.0'
> Makefile:263: recipe for target 'tmp.built' failed
> make: *** [tmp.built] Error 2
> error: Bad exit status from /var/tmp/rpm-tmp.2ykGhi (%build)



--
This message was sent by Atlassian JIRA
(v1000.571.2#100021)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-872) Re: [ovirt-devel] Gerrit headers are not added to commits in vdsm repo

[Barak Korren (oVirt JIRA)]

 [ 
https://ovirt-jira.atlassian.net/browse/OVIRT-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Barak Korren updated OVIRT-872:
---
Resolution: Won't Fix
Status: Done  (was: To Do)

This has to do with the maintainers`  chosen working mode for the Gerrit repo - 
as I replied in the mailing thread.
The maintainers need to the decide if they want to change it, and understand 
the consequences.

> Re: [ovirt-devel] Gerrit headers are not added to commits in vdsm repo
> --
>
> Key: OVIRT-872
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-872
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: eyal edri [Administrator]
>Assignee: infra
>
> I don't see any options to control this from project config, it will
> require more investigating to see if its a config option or only available
> via cherry-pick.
> opening a ticket to track this.
> On Sun, Nov 27, 2016 at 1:38 PM, Dan Kenigsberg  wrote:
> > On Sun, Nov 27, 2016 at 12:31:21PM +0200, Eyal Edri wrote:
> > > Not sure I understand what do you mean by Gerrit Headers.
> > > Can you give examples?
> > >
> > > On Fri, Nov 25, 2016 at 4:57 PM, Nir Soffer  wrote:
> > >
> > > > On Fri, Nov 25, 2016 at 4:45 PM, Tomáš Golembiovský <
> > tgole...@redhat.com>
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > I've noticed that in vdsm repo the merged commits do not contain the
> > > > > info headers added by Gerrit any more (Reviewed-by/Reviewed-on/etc.)
> > .
> > > > >
> > > > > Is that intentional? If yes, what was the motivation behind this?
> > > > >
> > > > > The change seem to have happened about 4 days ago. Sometime between
> > the
> > > > > following two commits:
> > > > >
> > > > > * 505f5da  API: Introduce getQemuImageInfo API. [Maor Lipchuk]
> > > > > * 1c4a39c  protocoldetector: Avoid unneeded getpeername() [Nir
> > Soffer]
> > > >
> > > > We switched vdsm to fast-forward 4 days ago, maybe this was unintended
> > > > side effect of this change?
> > > >
> > > > The gerrit headers are very useful, please add back.
> >
> >
> > https://gerrit.ovirt.org/#/c/66295/ is the last one which had them:
> >
> > Reviewed-on: https://gerrit.ovirt.org/66295
> > Reviewed-by: Nir Soffer 
> > Continuous-Integration: Jenkins CI
> >
> > they are added to the commit message during cherry-pick, and I find them
> > very useful.
> >
> -- 
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)



--
This message was sent by Atlassian JIRA
(v1000.571.2#100021)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [ovirt-devel] Gerrit headers are not added to commits in vdsm repo

[Barak Korren]

On 25 November 2016 at 16:57, Nir Soffer  wrote:
> On Fri, Nov 25, 2016 at 4:45 PM, Tomáš Golembiovský  
> wrote:
>> Hi,
>>
>> I've noticed that in vdsm repo the merged commits do not contain the
>> info headers added by Gerrit any more (Reviewed-by/Reviewed-on/etc.).
>>
>> Is that intentional? If yes, what was the motivation behind this?
>>
>> The change seem to have happened about 4 days ago. Sometime between the
>> following two commits:
>>
>> * 505f5da  API: Introduce getQemuImageInfo API. [Maor Lipchuk]
>> * 1c4a39c  protocoldetector: Avoid unneeded getpeername() [Nir Soffer]
>
> We switched vdsm to fast-forward 4 days ago, maybe this was unintended
> side effect of this change?
>
> The gerrit headers are very useful, please add back.
>

Headers cannot be added in fast-forward mode b/c then you end up with
a new commit hash - not fast forwarding to an existing commit.

In other words - headers are only added when Gerrit creates a new
commit - which in FF mode it never does.

I could move the project to "Rebase Always" which is like "Rebase if
Necessary" but always creates a new commit (with headers). Please note
that this is less strict then ff-only and therefore would lead to
merged combinations that do not get tested in CI.

-- 
Barak Korren
bkor...@redhat.com
RHEV-CI Team
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-872) Re: [ovirt-devel] Gerrit headers are not added to commits in vdsm repo

[eyal edri [Administrator] (oVirt JIRA)]

eyal edri [Administrator] created OVIRT-872:
---

 Summary: Re: [ovirt-devel] Gerrit headers are not added to commits 
in vdsm repo
 Key: OVIRT-872
 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-872
 Project: oVirt - virtualization made easy
  Issue Type: By-EMAIL
Reporter: eyal edri [Administrator]
Assignee: infra


I don't see any options to control this from project config, it will
require more investigating to see if its a config option or only available
via cherry-pick.
opening a ticket to track this.

On Sun, Nov 27, 2016 at 1:38 PM, Dan Kenigsberg  wrote:

> On Sun, Nov 27, 2016 at 12:31:21PM +0200, Eyal Edri wrote:
> > Not sure I understand what do you mean by Gerrit Headers.
> > Can you give examples?
> >
> > On Fri, Nov 25, 2016 at 4:57 PM, Nir Soffer  wrote:
> >
> > > On Fri, Nov 25, 2016 at 4:45 PM, Tomáš Golembiovský <
> tgole...@redhat.com>
> > > wrote:
> > > > Hi,
> > > >
> > > > I've noticed that in vdsm repo the merged commits do not contain the
> > > > info headers added by Gerrit any more (Reviewed-by/Reviewed-on/etc.)
> .
> > > >
> > > > Is that intentional? If yes, what was the motivation behind this?
> > > >
> > > > The change seem to have happened about 4 days ago. Sometime between
> the
> > > > following two commits:
> > > >
> > > > * 505f5da  API: Introduce getQemuImageInfo API. [Maor Lipchuk]
> > > > * 1c4a39c  protocoldetector: Avoid unneeded getpeername() [Nir
> Soffer]
> > >
> > > We switched vdsm to fast-forward 4 days ago, maybe this was unintended
> > > side effect of this change?
> > >
> > > The gerrit headers are very useful, please add back.
>
>
> https://gerrit.ovirt.org/#/c/66295/ is the last one which had them:
>
> Reviewed-on: https://gerrit.ovirt.org/66295
> Reviewed-by: Nir Soffer 
> Continuous-Integration: Jenkins CI
>
> they are added to the commit message during cherry-pick, and I find them
> very useful.
>



-- 
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)



--
This message was sent by Atlassian JIRA
(v1000.571.2#100021)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [ovirt-devel] Gerrit headers are not added to commits in vdsm repo

[Eyal Edri]

I don't see any options to control this from project config, it will
require more investigating to see if its a config option or only available
via cherry-pick.
opening a ticket to track this.

On Sun, Nov 27, 2016 at 1:38 PM, Dan Kenigsberg  wrote:

> On Sun, Nov 27, 2016 at 12:31:21PM +0200, Eyal Edri wrote:
> > Not sure I understand what do you mean by Gerrit Headers.
> > Can you give examples?
> >
> > On Fri, Nov 25, 2016 at 4:57 PM, Nir Soffer  wrote:
> >
> > > On Fri, Nov 25, 2016 at 4:45 PM, Tomáš Golembiovský <
> tgole...@redhat.com>
> > > wrote:
> > > > Hi,
> > > >
> > > > I've noticed that in vdsm repo the merged commits do not contain the
> > > > info headers added by Gerrit any more (Reviewed-by/Reviewed-on/etc.)
> .
> > > >
> > > > Is that intentional? If yes, what was the motivation behind this?
> > > >
> > > > The change seem to have happened about 4 days ago. Sometime between
> the
> > > > following two commits:
> > > >
> > > > * 505f5da  API: Introduce getQemuImageInfo API. [Maor Lipchuk]
> > > > * 1c4a39c  protocoldetector: Avoid unneeded getpeername() [Nir
> Soffer]
> > >
> > > We switched vdsm to fast-forward 4 days ago, maybe this was unintended
> > > side effect of this change?
> > >
> > > The gerrit headers are very useful, please add back.
>
>
> https://gerrit.ovirt.org/#/c/66295/ is the last one which had them:
>
> Reviewed-on: https://gerrit.ovirt.org/66295
> Reviewed-by: Nir Soffer 
> Continuous-Integration: Jenkins CI
>
> they are added to the commit message during cherry-pick, and I find them
> very useful.
>



-- 
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Jenkins build is back to normal : ovirt_3.6_he-system-tests #735

[jenkins]

See 

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-871) unrelated CI failure

[danken (oVirt JIRA)]

danken created OVIRT-871:


 Summary: unrelated CI failure
 Key: OVIRT-871
 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-871
 Project: oVirt - virtualization made easy
  Issue Type: By-EMAIL
Reporter: danken
Assignee: infra


Change https://gerrit.ovirt.org/#/c/67101/ just failed on

http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch-fc24-x86_64/8031/consoleText

which I believe is utterly unrelated to the patch. please resolved the 
underlying problem.



[ERROR] Failed to execute goal on project restapi-definition: Could not resolve 
dependencies for project 
org.ovirt.engine.api:restapi-definition:jar:4.1.0-SNAPSHOT: Failed to collect 
dependencies at org.ovirt.engine.api:metamodel-runtime:jar:1.1.8: Failed to 
read artifact descriptor for org.ovirt.engine.api:metamodel-runtime:jar:1.1.8: 
Could not transfer artifact org.ovirt.engine.api:metamodel-runtime:pom:1.1.8 
from/to ovirt-maven-repository 
(http://artifactory.ovirt.org/artifactory/ovirt-mirror): Failed to transfer 
file: 
http://artifactory.ovirt.org/artifactory/ovirt-mirror/org/ovirt/engine/api/metamodel-runtime/1.1.8/metamodel-runtime-1.1.8.pom.
 Return code is: 502 , ReasonPhrase:Proxy Error. -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :restapi-definition
Makefile:256: recipe for target 'maven' failed
make[1]: *** [maven] Error 1
make[1]: Leaving directory 
'/home/jenkins/workspace/ovirt-engine_master_check-patch-fc24-x86_64/ovirt-engine/rpmbuild/BUILD/ovirt-engine-4.1.0'
Makefile:263: recipe for target 'tmp.built' failed
make: *** [tmp.built] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.2ykGhi (%build)



--
This message was sent by Atlassian JIRA
(v1000.571.2#100021)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-870) Access to artifactory.ovirt.org is slow

[eyal edri [Administrator] (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23309#comment-23309
 ] 

eyal edri [Administrator] commented on OVIRT-870:
-

Gil is looking into it.

On Sun, Nov 27, 2016 at 1:28 PM, Juan Hernández (oVirt JIRA) <



-- 
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)


> Access to artifactory.ovirt.org is slow
> ---
>
> Key: OVIRT-870
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-870
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: Juan Hernández
>Assignee: infra
>
> Access to artifactory.ovirt.org seems to be very slow now. For example,
> in the following build:
> http://jenkins.ovirt.org/job/ovirt-engine-api-model_master_check-patch-fc24-x86_64/217/consoleText
> It is responding with a transfer rate of 0.2 KiB per second:
>   Downloaded:
> http://artifactory.ovirt.org/artifactory/ovirt-mirror/org/apache/maven/plugins/maven-source-plugin/2.4/maven-source-plugin-2.4.pom
> (7 KB at 0.2 KB/sec)
> Can this be improved?
> -- 
> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> 3ºD, 28016 Madrid, Spain
> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.



--
This message was sent by Atlassian JIRA
(v1000.571.2#100021)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [JIRA] (OVIRT-870) Access to artifactory.ovirt.org is slow

[Eyal Edri]

Gil is looking into it.

On Sun, Nov 27, 2016 at 1:28 PM, Juan Hernández (oVirt JIRA) <
j...@ovirt-jira.atlassian.net> wrote:

>
> [ https://ovirt-jira.atlassian.net/browse/OVIRT-870?page=com.
> atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=23308#comment-23308 ]
>
> Juan Hernández commented on OVIRT-870:
> --
>
> Note that eventually the build fails, with a 502 HTTP error code:
>
> {{[ERROR] Failed to execute goal on project model: Could not resolve
> dependencies for project org.ovirt.engine.api:model:jar:4.1.21-SNAPSHOT:
> Failed to collect dependencies at org.ovirt.engine.api:
> metamodel-annotations:jar:1.1.9: Failed to read artifact descriptor for
> org.ovirt.engine.api:metamodel-annotations:jar:1.1.9: Could not transfer
> artifact org.ovirt.engine.api:metamodel-annotations:pom:1.1.9 from/to
> ovirt-artifactory (http://artifactory.ovirt.org/artifactory/ovirt-mirror):
> Failed to transfer file: http://artifactory.ovirt.org/
> artifactory/ovirt-mirror/org/ovirt/engine/api/metamodel-
> annotations/1.1.9/metamodel-annotations-1.1.9.pom. Return code is: 502 ,
> ReasonPhrase:Proxy Error. -> [Help 1]}}
>
> > Access to artifactory.ovirt.org is slow
> > ---
> >
> > Key: OVIRT-870
> > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-870
> > Project: oVirt - virtualization made easy
> >  Issue Type: By-EMAIL
> >Reporter: Juan Hernández
> >Assignee: infra
> >
> > Access to artifactory.ovirt.org seems to be very slow now. For example,
> > in the following build:
> > http://jenkins.ovirt.org/job/ovirt-engine-api-model_master_
> check-patch-fc24-x86_64/217/consoleText
> > It is responding with a transfer rate of 0.2 KiB per second:
> >   Downloaded:
> > http://artifactory.ovirt.org/artifactory/ovirt-mirror/org/
> apache/maven/plugins/maven-source-plugin/2.4/maven-source-plugin-2.4.pom
> > (7 KB at 0.2 KB/sec)
> > Can this be improved?
> > --
> > Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> > 3ºD, 28016 Madrid, Spain
> > Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v1000.571.2#100021)
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
>
>


-- 
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3697 - SUCCESS!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3697/,
Build Number: 3697,
Build Status: SUCCESS___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [ovirt-devel] Gerrit headers are not added to commits in vdsm repo

[Dan Kenigsberg]

On Sun, Nov 27, 2016 at 12:31:21PM +0200, Eyal Edri wrote:
> Not sure I understand what do you mean by Gerrit Headers.
> Can you give examples?
> 
> On Fri, Nov 25, 2016 at 4:57 PM, Nir Soffer  wrote:
> 
> > On Fri, Nov 25, 2016 at 4:45 PM, Tomáš Golembiovský 
> > wrote:
> > > Hi,
> > >
> > > I've noticed that in vdsm repo the merged commits do not contain the
> > > info headers added by Gerrit any more (Reviewed-by/Reviewed-on/etc.).
> > >
> > > Is that intentional? If yes, what was the motivation behind this?
> > >
> > > The change seem to have happened about 4 days ago. Sometime between the
> > > following two commits:
> > >
> > > * 505f5da  API: Introduce getQemuImageInfo API. [Maor Lipchuk]
> > > * 1c4a39c  protocoldetector: Avoid unneeded getpeername() [Nir Soffer]
> >
> > We switched vdsm to fast-forward 4 days ago, maybe this was unintended
> > side effect of this change?
> >
> > The gerrit headers are very useful, please add back.


https://gerrit.ovirt.org/#/c/66295/ is the last one which had them:

Reviewed-on: https://gerrit.ovirt.org/66295
Reviewed-by: Nir Soffer 
Continuous-Integration: Jenkins CI

they are added to the commit message during cherry-pick, and I find them
very useful.
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [ovirt-devel] Gerrit headers are not added to commits in vdsm repo

[Nir Soffer]

On Sun, Nov 27, 2016 at 12:31 PM, Eyal Edri  wrote:
> Not sure I understand what do you mean by Gerrit Headers.
> Can you give examples?

Here the point when the header disappeared:

commit 82bebee084cb9841a42cc9131a724362771a2c80
Author: Petr Horáček 
Date:   Wed Nov 16 15:28:01 2016 +0100

net: enable link.bond to handle options

Note that this change also requires change in slaves editation
(in _revert_transaction) since we cannot edit options of a bonding
with attached slaves.

Change-Id: I4399432347dc00f11d6bea28d731dd6e37914c20
Signed-off-by: Petr Horáček 
Bug-Url: https://bugzilla.redhat.com/1379115

commit 505f5da01785ece0e238a7fa3125358b67595d69
Author: Maor Lipchuk 
Date:   Wed Nov 9 16:01:04 2016 +0200

API: Introduce getQemuImageInfo API.

The new API suppose to return information fetched using qemuimg info.
This should be usable to get the compat version of the volume.

This API will not use a job since it only returns information
about the volume and do not change it.
It is similar to how getVolumeInfo is working.

Change-Id: Ic170e2f142e8e70b534083c9468d249fe2478943
Signed-off-by: Maor Lipchuk 
Reviewed-on: https://gerrit.ovirt.org/66295
Reviewed-by: Nir Soffer 
Continuous-Integration: Jenkins CI

Note that the older commit had:

- Reviewed-on:
- Reviewed-by:
- Continuous-Integration:

>
> On Fri, Nov 25, 2016 at 4:57 PM, Nir Soffer  wrote:
>>
>> On Fri, Nov 25, 2016 at 4:45 PM, Tomáš Golembiovský 
>> wrote:
>> > Hi,
>> >
>> > I've noticed that in vdsm repo the merged commits do not contain the
>> > info headers added by Gerrit any more (Reviewed-by/Reviewed-on/etc.).
>> >
>> > Is that intentional? If yes, what was the motivation behind this?
>> >
>> > The change seem to have happened about 4 days ago. Sometime between the
>> > following two commits:
>> >
>> > * 505f5da  API: Introduce getQemuImageInfo API. [Maor Lipchuk]
>> > * 1c4a39c  protocoldetector: Avoid unneeded getpeername() [Nir Soffer]
>>
>> We switched vdsm to fast-forward 4 days ago, maybe this was unintended
>> side effect of this change?
>>
>> The gerrit headers are very useful, please add back.
>>
>> Nir
>> ___
>> Infra mailing list
>> Infra@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/infra
>>
>>
>
>
>
> --
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
>
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3696 - FAILURE!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3696/,
Build Number: 3696,
Build Status: FAILURE___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-870) Access to artifactory.ovirt.org is slow

[oVirt JIRA]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23308#comment-23308
 ] 

Juan Hernández commented on OVIRT-870:
--

Note that eventually the build fails, with a 502 HTTP error code:

{{[ERROR] Failed to execute goal on project model: Could not resolve 
dependencies for project org.ovirt.engine.api:model:jar:4.1.21-SNAPSHOT: Failed 
to collect dependencies at 
org.ovirt.engine.api:metamodel-annotations:jar:1.1.9: Failed to read artifact 
descriptor for org.ovirt.engine.api:metamodel-annotations:jar:1.1.9: Could not 
transfer artifact org.ovirt.engine.api:metamodel-annotations:pom:1.1.9 from/to 
ovirt-artifactory (http://artifactory.ovirt.org/artifactory/ovirt-mirror): 
Failed to transfer file: 
http://artifactory.ovirt.org/artifactory/ovirt-mirror/org/ovirt/engine/api/metamodel-annotations/1.1.9/metamodel-annotations-1.1.9.pom.
 Return code is: 502 , ReasonPhrase:Proxy Error. -> [Help 1]}}

> Access to artifactory.ovirt.org is slow
> ---
>
> Key: OVIRT-870
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-870
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: Juan Hernández
>Assignee: infra
>
> Access to artifactory.ovirt.org seems to be very slow now. For example,
> in the following build:
> http://jenkins.ovirt.org/job/ovirt-engine-api-model_master_check-patch-fc24-x86_64/217/consoleText
> It is responding with a transfer rate of 0.2 KiB per second:
>   Downloaded:
> http://artifactory.ovirt.org/artifactory/ovirt-mirror/org/apache/maven/plugins/maven-source-plugin/2.4/maven-source-plugin-2.4.pom
> (7 KB at 0.2 KB/sec)
> Can this be improved?
> -- 
> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> 3ºD, 28016 Madrid, Spain
> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.



--
This message was sent by Atlassian JIRA
(v1000.571.2#100021)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-870) Access to artifactory.ovirt.org is slow

[oVirt JIRA]

Juan Hernández created OVIRT-870:


 Summary: Access to artifactory.ovirt.org is slow
 Key: OVIRT-870
 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-870
 Project: oVirt - virtualization made easy
  Issue Type: By-EMAIL
Reporter: Juan Hernández
Assignee: infra


Access to artifactory.ovirt.org seems to be very slow now. For example,
in the following build:


http://jenkins.ovirt.org/job/ovirt-engine-api-model_master_check-patch-fc24-x86_64/217/consoleText

It is responding with a transfer rate of 0.2 KiB per second:

  Downloaded:
http://artifactory.ovirt.org/artifactory/ovirt-mirror/org/apache/maven/plugins/maven-source-plugin/2.4/maven-source-plugin-2.4.pom
(7 KB at 0.2 KB/sec)

Can this be improved?

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.



--
This message was sent by Atlassian JIRA
(v1000.571.2#100021)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Build failed in Jenkins: ovirt_4.0_he-system-tests #560

[Eyal Edri]

I see it was fixed.

Do we know the cause and what fixed it?

On Fri, Nov 25, 2016 at 2:17 PM, Sandro Bonazzola 
wrote:

> Error: Package: 7:lvm2-2.02.166-1.el7_3.1.x86_64 (alocalsync)
>Requires: device-mapper-persistent-data >= 0.6.3-1
>Available: device-mapper-persistent-data-0.5.5-1.el7.x86_64 
> (alocalsync)
>device-mapper-persistent-data = 0.5.5-1.el7
>
>
> Still repository error
>
>
> On Fri, Nov 25, 2016 at 12:41 PM,  wrote:
>
>> See 
>>
>> Changes:
>>
>> [Eyal Edri] adding missing python-simplejson to epel repo
>>
>> --
>> [...truncated 669 lines...]
>> ##  took 356 seconds
>> ##  rc = 1
>> ##
>> ##! ERROR v
>> ##! Last 20 log entries: logs/mocker-epel-7-x86_64.el7.
>> he_basic_suite_4.0.sh/he_basic_suite_4.0.sh.log
>> ##!
>> + env_cleanup
>> + echo '#'
>> #
>> + local res=0
>> + local uuid
>> + echo ' Cleaning up'
>>  Cleaning up
>> + [[ -e > virt-system-tests/deployment-he-basic-suite-4.0> ]]
>> + echo '--- Cleaning with lago'
>> --- Cleaning with lago
>> + lago --workdir > ovirt_4.0_he-system-tests/ws/ovirt-system-tests/deployment-h
>> e-basic-suite-4.0> destroy --yes --all-prefixes
>> + echo '--- Cleaning with lago done'
>> --- Cleaning with lago done
>> + [[ 0 != \0 ]]
>> + echo ' Cleanup done'
>>  Cleanup done
>> + exit 0
>> + exit
>> Took 205 seconds
>> ===
>> ##!
>> ##! ERROR ^^
>> ##!
>> ##
>> Build step 'Execute shell' marked build as failure
>> Performing Post build task...
>> Match found for :.* : True
>> Logical operation result is TRUE
>> Running script  : #!/bin/bash -xe
>> echo 'shell_scripts/system_tests.collect_logs.sh'
>>
>> #
>> # Required jjb vars:
>> #version
>> #
>> VERSION=4.0
>> SUITE_TYPE=
>>
>> WORKSPACE="$PWD"
>> OVIRT_SUITE="$SUITE_TYPE_suite_$VERSION"
>> TESTS_LOGS="$WORKSPACE/ovirt-system-tests/exported-artifacts"
>>
>> rm -rf "$WORKSPACE/exported-artifacts"
>> mkdir -p "$WORKSPACE/exported-artifacts"
>>
>> if [[ -d "$TESTS_LOGS" ]]; then
>> mv "$TESTS_LOGS/"* "$WORKSPACE/exported-artifacts/"
>> fi
>>
>> [ovirt_4.0_he-system-tests] $ /bin/bash -xe /tmp/hudson5732644382445829429
>> .sh
>> + echo shell_scripts/system_tests.collect_logs.sh
>> shell_scripts/system_tests.collect_logs.sh
>> + VERSION=4.0
>> + SUITE_TYPE=
>> + WORKSPACE=
>> + OVIRT_SUITE=4.0
>> + TESTS_LOGS=> -tests/ws/ovirt-system-tests/exported-artifacts>
>> + rm -rf > artifact/exported-artifacts>
>> + mkdir -p > artifact/exported-artifacts>
>> + [[ -d > virt-system-tests/exported-artifacts> ]]
>> + mv > virt-system-tests/exported-artifacts/lago_logs> <
>> http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/560/
>> artifact/exported-artifacts/>
>> POST BUILD TASK : SUCCESS
>> END OF POST BUILD TASK : 0
>> Match found for :.* : True
>> Logical operation result is TRUE
>> Running script  : #!/bin/bash -xe
>> echo "shell-scripts/mock_cleanup.sh"
>>
>> shopt -s nullglob
>>
>>
>> WORKSPACE="$PWD"
>>
>> # Make clear this is the cleanup, helps reading the jenkins logs
>> cat <> ___
>> ###
>> # #
>> #   CLEANUP   #
>> # #
>> ###
>> EOC
>>
>>
>> # Archive the logs, we want them anyway
>> logs=(
>> ./*log
>> ./*/logs
>> )
>>
>> if [[ "$logs" ]]; then
>> for log in "${logs[@]}"
>> do
>> echo "Copying ${log} to exported-artifacts"
>> mv $log exported-artifacts/
>> done
>> fi
>>
>> # stop any processes running inside the chroot
>> failed=false
>> mock_confs=("$WORKSPACE"/*/mocker*)
>> # Clean current jobs mockroot if any
>> for mock_conf_file in "${mock_confs[@]}"; do
>> [[ "$mock_conf_file" ]] || continue
>> echo "Cleaning up mock $mock_conf"

Re: [ovirt-devel] Gerrit headers are not added to commits in vdsm repo

[Eyal Edri]

Not sure I understand what do you mean by Gerrit Headers.
Can you give examples?

On Fri, Nov 25, 2016 at 4:57 PM, Nir Soffer  wrote:

> On Fri, Nov 25, 2016 at 4:45 PM, Tomáš Golembiovský 
> wrote:
> > Hi,
> >
> > I've noticed that in vdsm repo the merged commits do not contain the
> > info headers added by Gerrit any more (Reviewed-by/Reviewed-on/etc.).
> >
> > Is that intentional? If yes, what was the motivation behind this?
> >
> > The change seem to have happened about 4 days ago. Sometime between the
> > following two commits:
> >
> > * 505f5da  API: Introduce getQemuImageInfo API. [Maor Lipchuk]
> > * 1c4a39c  protocoldetector: Avoid unneeded getpeername() [Nir Soffer]
>
> We switched vdsm to fast-forward 4 days ago, maybe this was unintended
> side effect of this change?
>
> The gerrit headers are very useful, please add back.
>
> Nir
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
>
>


-- 
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-867) Re: [oVirt Jenkins] repos_3.6_check-closure_el7_merged - Build # 92 - Still Failing!

[eyal edri [Administrator] (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23307#comment-23307
 ] 

eyal edri [Administrator] commented on OVIRT-867:
-

Evgheni,

Looks like we're hitting too much issues lately with external repos (
epel/centos/fedora ),
I think its time we'll consider having a mirror for what we need on
resources.ovirt.org to reduce the failures ( we need to ensure we have
enough space on it as well )

On Fri, Nov 25, 2016 at 5:13 PM, Sandro Bonazzola 
wrote:

>
>
> On Fri, Nov 25, 2016 at 3:43 PM, Evgheni Dereveanchin  > wrote:
>
>> After more checks - indeed this looks like an inconsistency
>> on the mirror:
>>
>> http://mirror.switch.ch/ftp/mirror/epel/7/x86_64/repodata/
>>
>> 1ef1290202fb9e09f1aa15efccea3456913df8657cc0e23a1df61d9ec18
>> e5659-comps-epel7.xml.xz
>> ab638ffbf7ef7e7f41b8f630113ff6bd251612eefa570b8725b612500d8
>> c90fc-comps-epel7.xml
>> repomd.xml
>>
>> there is no primary.sqlite.xz or filelists.xml.gz in this directory
>> at the moment, hence the failures. As said, this mirror is hardcoded
>> in repo_closure_check.sh so changing that to a working mirror will
>> fix the issue, as well as waiting till mirror.switch.ch gets sync'ed.
>>
>> In fact, I don't know why we are using a Swiss mirror for tests that
>> are run on US servers.
>>
>>
> feel free to change mirror or use a local one
>
>
>
>> Regards,
>> Evgheni Dereveanchin
>>
>> - Original Message -
>> From: "Evgheni Dereveanchin" 
>> To: "Sandro Bonazzola" 
>> Cc: "infra" , infra-supp...@ovirt.org, "Yedidyah Bar
>> David" , "Eyal Edri" 
>> Sent: Friday, 25 November, 2016 3:10:47 PM
>> Subject: Re: [oVirt Jenkins] repos_3.6_check-closure_el7_merged - Build
>> # 92 - Still Failing!
>>
>> Hi Sandro,
>>
>> From first glance this may be caused by an upstream EPEL mirror,
>> especially given the 404 errors:
>>
>> 12:07:12 Added check-epel-el7 repo from http://mirror.switch.ch/ftp/mi
>> rror/epel/7/x86_64/
>> ...
>> 12:07:12 Reading in repository metadata - please wait
>> 12:07:20 Can't download or revert repomd.xml for check-epel-el7
>> ...
>> 12:07:21 failure: repodata/9edce4d5e3c9437849fbb
>> bae7c2faa50a9b0326b968dd8faa66ece83984c23de-primary.sqlite.xz from
>> check-epel-el7: [Errno 256] No more mirrors to try.
>> 12:07:21 http://mirror.switch.ch/ftp/mirror/epel/7/x86_64/repodata/9e
>> dce4d5e3c9437849fbbbae7c2faa50a9b0326b968dd8faa66ece83984c23
>> de-primary.sqlite.xz: [Errno 14] HTTP Error 404 - Not Found
>>
>> This mirror is hardcoded in repo_closure_check.sh and looks
>> fine when accessed by browser. I will do some more investigation
>> to see if some stale metadata may be causing this, however I've
>> seen the failure on several different slaves.
>>
>> Regards,
>> Evgheni Dereveanchin
>>
>> - Original Message -
>> From: "Sandro Bonazzola" 
>> To: "infra" , infra-supp...@ovirt.org, "Evgheni
>> Dereveanchin" 
>> Cc: "Yedidyah Bar David" , "Eyal Edri" > >
>> Sent: Friday, 25 November, 2016 2:41:02 PM
>> Subject: Re: [oVirt Jenkins] repos_3.6_check-closure_el7_merged - Build
>> # 92 - Still Failing!
>>
>> *00:01:53.955* Can't download or revert repomd.xml for
>> check-epel-el7*00:01:53.955* Some dependencies may not be complete for
>> this repository*00:01:53.956* Run as root to get all dependencies or
>> use -t to enable a user temp cache
>>
>>
>> Can you check? looks like it's not possible to update local cache of
>> metadata.
>>
>>
>>
>> On Fri, Nov 25, 2016 at 1:07 PM,  wrote:
>>
>> > Project: http://jenkins.ovirt.org/job/repos_3.6_check-closure_el7_mer
>> ged/
>> > Build: http://jenkins.ovirt.org/job/repos_3.6_check-closure_el7_mer
>> ged/92/
>> > Build Number: 92
>> > Build Status:  Still Failing
>> > Triggered By: Started by user Sandro Bonazzola
>> >
>> > -
>> > Changes Since Last Success:
>> > -
>> > Changes for Build #89
>> > [Eyal Edri] deploy ovirt-engine-cli 3.6 to 4.0 and master repos as well
>> >
>> > [Yedidyah Bar David] master_upgrade_from_master: Upgrade to self instead
>> > of snapshot
>> >
>> >
>> > Changes for Build #90
>> > No changes
>> >
>> > Changes for Build #91
>> > No changes
>> >
>> > Changes for Build #92
>> > No changes
>> >
>> >
>> >
>> > -
>> > Failed Tests:
>> > -
>> > No tests ran.
>> >
>> >
>> > ___
>> > Infra mailing list
>> > Infra@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/infra
>> >
>> >
>>
>>
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community collaboration.
>> See how it works at redhat.com
>>
>
>
>
> --
> 

Re: [oVirt Jenkins] repos_3.6_check-closure_el7_merged - Build # 92 - Still Failing!

[Eyal Edri]

Evgheni,

Looks like we're hitting too much issues lately with external repos (
epel/centos/fedora ),
I think its time we'll consider having a mirror for what we need on
resources.ovirt.org to reduce the failures ( we need to ensure we have
enough space on it as well )

On Fri, Nov 25, 2016 at 5:13 PM, Sandro Bonazzola 
wrote:

>
>
> On Fri, Nov 25, 2016 at 3:43 PM, Evgheni Dereveanchin  > wrote:
>
>> After more checks - indeed this looks like an inconsistency
>> on the mirror:
>>
>> http://mirror.switch.ch/ftp/mirror/epel/7/x86_64/repodata/
>>
>> 1ef1290202fb9e09f1aa15efccea3456913df8657cc0e23a1df61d9ec18
>> e5659-comps-epel7.xml.xz
>> ab638ffbf7ef7e7f41b8f630113ff6bd251612eefa570b8725b612500d8
>> c90fc-comps-epel7.xml
>> repomd.xml
>>
>> there is no primary.sqlite.xz or filelists.xml.gz in this directory
>> at the moment, hence the failures. As said, this mirror is hardcoded
>> in repo_closure_check.sh so changing that to a working mirror will
>> fix the issue, as well as waiting till mirror.switch.ch gets sync'ed.
>>
>> In fact, I don't know why we are using a Swiss mirror for tests that
>> are run on US servers.
>>
>>
> feel free to change mirror or use a local one
>
>
>
>> Regards,
>> Evgheni Dereveanchin
>>
>> - Original Message -
>> From: "Evgheni Dereveanchin" 
>> To: "Sandro Bonazzola" 
>> Cc: "infra" , infra-supp...@ovirt.org, "Yedidyah Bar
>> David" , "Eyal Edri" 
>> Sent: Friday, 25 November, 2016 3:10:47 PM
>> Subject: Re: [oVirt Jenkins] repos_3.6_check-closure_el7_merged - Build
>> # 92 - Still Failing!
>>
>> Hi Sandro,
>>
>> From first glance this may be caused by an upstream EPEL mirror,
>> especially given the 404 errors:
>>
>> 12:07:12 Added check-epel-el7 repo from http://mirror.switch.ch/ftp/mi
>> rror/epel/7/x86_64/
>> ...
>> 12:07:12 Reading in repository metadata - please wait
>> 12:07:20 Can't download or revert repomd.xml for check-epel-el7
>> ...
>> 12:07:21 failure: repodata/9edce4d5e3c9437849fbb
>> bae7c2faa50a9b0326b968dd8faa66ece83984c23de-primary.sqlite.xz from
>> check-epel-el7: [Errno 256] No more mirrors to try.
>> 12:07:21 http://mirror.switch.ch/ftp/mirror/epel/7/x86_64/repodata/9e
>> dce4d5e3c9437849fbbbae7c2faa50a9b0326b968dd8faa66ece83984c23
>> de-primary.sqlite.xz: [Errno 14] HTTP Error 404 - Not Found
>>
>> This mirror is hardcoded in repo_closure_check.sh and looks
>> fine when accessed by browser. I will do some more investigation
>> to see if some stale metadata may be causing this, however I've
>> seen the failure on several different slaves.
>>
>> Regards,
>> Evgheni Dereveanchin
>>
>> - Original Message -
>> From: "Sandro Bonazzola" 
>> To: "infra" , infra-supp...@ovirt.org, "Evgheni
>> Dereveanchin" 
>> Cc: "Yedidyah Bar David" , "Eyal Edri" > >
>> Sent: Friday, 25 November, 2016 2:41:02 PM
>> Subject: Re: [oVirt Jenkins] repos_3.6_check-closure_el7_merged - Build
>> # 92 - Still Failing!
>>
>> *00:01:53.955* Can't download or revert repomd.xml for
>> check-epel-el7*00:01:53.955* Some dependencies may not be complete for
>> this repository*00:01:53.956* Run as root to get all dependencies or
>> use -t to enable a user temp cache
>>
>>
>> Can you check? looks like it's not possible to update local cache of
>> metadata.
>>
>>
>>
>> On Fri, Nov 25, 2016 at 1:07 PM,  wrote:
>>
>> > Project: http://jenkins.ovirt.org/job/repos_3.6_check-closure_el7_mer
>> ged/
>> > Build: http://jenkins.ovirt.org/job/repos_3.6_check-closure_el7_mer
>> ged/92/
>> > Build Number: 92
>> > Build Status:  Still Failing
>> > Triggered By: Started by user Sandro Bonazzola
>> >
>> > -
>> > Changes Since Last Success:
>> > -
>> > Changes for Build #89
>> > [Eyal Edri] deploy ovirt-engine-cli 3.6 to 4.0 and master repos as well
>> >
>> > [Yedidyah Bar David] master_upgrade_from_master: Upgrade to self instead
>> > of snapshot
>> >
>> >
>> > Changes for Build #90
>> > No changes
>> >
>> > Changes for Build #91
>> > No changes
>> >
>> > Changes for Build #92
>> > No changes
>> >
>> >
>> >
>> > -
>> > Failed Tests:
>> > -
>> > No tests ran.
>> >
>> >
>> > ___
>> > Infra mailing list
>> > Infra@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/infra
>> >
>> >
>>
>>
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community collaboration.
>> See how it works at redhat.com
>>
>
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
>



-- 
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on 

[JIRA] (OVIRT-869) Investigate proxy errors from proxy.phx.ovirt.org

[Barak Korren (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23306#comment-23306
 ] 

Barak Korren commented on OVIRT-869:


{quote}
It currently has :127.0.0.1 proxy.phx.ovirt.org
Do you mean adding the public IP address as well?
{quote}

If it has this already then the error is strange indeed, all I can think of is 
that maybe the mock environment running the failed job was not configured 
correctly (Trying to use the proxy repo URLs without setting it up as an HTTP 
proxy _in addition to_ not having proper _DNS_ config. If it was justh the HTTP 
proxy setting I would expect to see a "_connection refused_" error rather then 
"_could not resolve_").

{quote}
By full fledged mirrors you mean have it on resources.ovirt.org ? will we need 
Katello to manage them or mirror with rsync will suffice? 
{quote}

Not necessarily on resources.ovirt.org, we could (and maybe should) use a 
different server for that.
WRT the mirroring solution itself we have many options with varying degrees of 
automation, features and required effort:
# rsync (though not all upsreams may allow this kind of access)
# yum reposync
# repoman
# Pulp
# Artifactory
# Katello

The benefit of Katello would be in allowing us to control exactly which 
packages get tested by leveraging the work flow environments and the content 
views, but we could build comparable solutions with other tools.

> Investigate proxy errors from proxy.phx.ovirt.org
> -
>
> Key: OVIRT-869
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-869
> Project: oVirt - virtualization made easy
>  Issue Type: Bug
>Reporter: eyal edri [Administrator]
>Assignee: infra
>Priority: Highest
>
> We need to make sure jobs don't fail on proxy like [1].
> Either use original repos if proxy is down or add watchdog / alerts for the 
> proxy service.
> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3693/artifact/exported-artifacts/basic_suite_master.sh-el7/logs/mocker-epel-7-x86_64.el7.init/root.log



--
This message was sent by Atlassian JIRA
(v1000.571.2#100021)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Change in ovirt-engine[master]: core: improving vms_with_tags view performance

[Eyal Edri]

Thanks for reporting.
it had an old cherry pick of a patch tested.

Daniel - please make sure to remove any manual cp done on a job when the
patch is merged.
I removed it from the job, should work now.

On Fri, Nov 25, 2016 at 8:54 PM, Martin Perina  wrote:

> Could you please take a look at upgrade from 3.6 job? Following error
> seems to me like an CI infra issue:
>
> error: could not apply 8525684... Modified cleanup.sh in 'upgrade_to_4.0'
>
>
> Thanks
>
> Martin
>
>
>
> On Fri, Nov 25, 2016 at 6:54 PM, Code Review  wrote:
>
>> From Jenkins CI:
>>
>> Jenkins CI has posted comments on this change.
>>
>> Change subject: core: improving vms_with_tags view performance
>> 
>>
>>
>> Patch Set 4:
>>
>> Build Failed
>>
>> http://jenkins.ovirt.org/job/ovirt-engine_master_upgrade-fro
>> m-3.6_el7_merged/1039/ : FAILURE
>>
>> http://jenkins.ovirt.org/job/ovirt-engine_master_check-merge
>> d-el7-x86_64/2650/ : SUCCESS
>>
>> http://jenkins.ovirt.org/job/ovirt-engine_master_upgrade-fro
>> m-4.0_el7_merged/2183/ : SUCCESS
>>
>> http://jenkins.ovirt.org/job/ovirt-engine_master_upgrade-fro
>> m-master_el7_merged/2657/ : SUCCESS
>>
>> http://jenkins.ovirt.org/job/ovirt-engine_master_check-merge
>> d-fc24-x86_64/1753/ : SUCCESS
>>
>> --
>> To view, visit https://gerrit.ovirt.org/66165
>> To unsubscribe, visit https://gerrit.ovirt.org/settings
>>
>> Gerrit-MessageType: comment
>> Gerrit-Change-Id: Ib5a6637b7c890e445940c8d0a770c2bd7e11e72b
>> Gerrit-PatchSet: 4
>> Gerrit-Project: ovirt-engine
>> Gerrit-Branch: master
>> Gerrit-Owner: Eli Mesika 
>> Gerrit-Reviewer: Arik Hadas 
>> Gerrit-Reviewer: Eli Mesika 
>> Gerrit-Reviewer: Jenkins CI
>> Gerrit-Reviewer: Martin Peřina 
>> Gerrit-Reviewer: gerrit-hooks 
>> Gerrit-HasComments: No
>>
>
>
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
>


-- 
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-869) Investigate proxy errors from proxy.phx.ovirt.org

[eyal edri [Administrator] (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23305#comment-23305
 ] 

eyal edri [Administrator] commented on OVIRT-869:
-

bq. Port 5000 is where the python script is running no? So the Squid had an 
issue resolving the name of the very host it is running on? We should probably 
just resolve this forever by placing the name in /etc/hosts on the proxy 
server

It currently has :127.0.0.1   proxy.phx.ovirt.org
Do you mean adding the public IP address as well?

bq. Typically the failures we're seeing are because of failures in the origin 
mirror we are actually proxying (Fedora and EPEL seem to be notoriously 
non-atomic when updating their mirrors). The way to solve this is only to used 
fully-fledged mirrors instead of a proxy (But this takes more maintenance and 
more storage).

By full fledged mirrors you mean have it on resources.ovirt.org ? will we need 
Katello to manage them or mirror with rsync will suffice? 

> Investigate proxy errors from proxy.phx.ovirt.org
> -
>
> Key: OVIRT-869
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-869
> Project: oVirt - virtualization made easy
>  Issue Type: Bug
>Reporter: eyal edri [Administrator]
>Assignee: infra
>Priority: Highest
>
> We need to make sure jobs don't fail on proxy like [1].
> Either use original repos if proxy is down or add watchdog / alerts for the 
> proxy service.
> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3693/artifact/exported-artifacts/basic_suite_master.sh-el7/logs/mocker-epel-7-x86_64.el7.init/root.log



--
This message was sent by Atlassian JIRA
(v1000.571.2#100021)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3694 - SUCCESS!

[jenkins]

Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3694/,
Build Number: 3694,
Build Status: SUCCESS___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-869) Investigate proxy errors from proxy.phx.ovirt.org

[Barak Korren (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23301#comment-23301
 ] 

Barak Korren edited comment on OVIRT-869 at 11/27/16 10:50 AM:
---

The error seems to be a DNS error:
{code}
DEBUG util.py:421:  
http://proxy.phx.ovirt.org:5000/centos-base/7/x86_64/Packages/unzip-6.0-15.el7.x86_64.rpm:
 [Errno 14] curl#5 - "Could not resolve proxy: proxy.phx.ovirt.org"
{code}

Port 5000 is where the python script is running no? So the Squid had an issue 
resolving the name of the very host it is running on? We should probably just 
resolve this forever by placing the name in {{/etc/hosts}} on the proxy 
server

{quote}
Either use original repos if proxy is down or add watchdog / alerts for the 
proxy service.
{quote}
We have this:
# {{mock_runner.sh}} tries to contact proxy and uses un-proxyed configuration 
if it fails (This is why it has both {{\*.cnf}} and {{*-proxy.cnf}} files)
# There is a cron job watchdog running on the proxy itself and restarting it
# AFAIK we also have Icinga monitoring it.

Typically the failures we're seeing are because of failures in the origin 
mirror we are actually proxying (Fedora and EPEL seem to be notoriously 
non-atomic when updating their mirrors). The way to solve this is only to used 
fully-fledged mirrors instead of a proxy (But this takes more maintenance and 
more storage). 



was (Author: bkor...@redhat.com):
The error seems to be a DNS error:
{code}
DEBUG util.py:421:  
http://proxy.phx.ovirt.org:5000/centos-base/7/x86_64/Packages/unzip-6.0-15.el7.x86_64.rpm:
 [Errno 14] curl#5 - "Could not resolve proxy: proxy.phx.ovirt.org"
{code}

Port 5000 is where the python script is running no? So the Squid had an issue 
resolving the name of the very host it is running on? We should probably just 
resolve this forever by placing the name in {{/etc/hosts}} on the proxy 
server

{code}
Either use original repos if proxy is down or add watchdog / alerts for the 
proxy service.
{code}
We have this:
# {{mock_runner.sh}} tries to contact proxy and uses un-proxyed configuration 
if it fails (This is why it has both {{\*.cnf}} and {{*-proxy.cnf}} files)
# There is a cron job watchdog running on the proxy itself and restarting it
# AFAIK we also have Icinga monitoring it.

Typically the failures we're seeing are because of failures in the origin 
mirror we are actually proxying (Fedora and EPEL seem to be notoriously 
non-atomic when updating their mirrors). The way to solve this is only to used 
fully-fledged mirrors instead of a proxy (But this takes more maintenance and 
more storage). 


> Investigate proxy errors from proxy.phx.ovirt.org
> -
>
> Key: OVIRT-869
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-869
> Project: oVirt - virtualization made easy
>  Issue Type: Bug
>Reporter: eyal edri [Administrator]
>Assignee: infra
>Priority: Highest
>
> We need to make sure jobs don't fail on proxy like [1].
> Either use original repos if proxy is down or add watchdog / alerts for the 
> proxy service.
> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3693/artifact/exported-artifacts/basic_suite_master.sh-el7/logs/mocker-epel-7-x86_64.el7.init/root.log



--
This message was sent by Atlassian JIRA
(v1000.571.2#100021)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-869) Investigate proxy errors from proxy.phx.ovirt.org

[Barak Korren (oVirt JIRA)]

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23301#comment-23301
 ] 

Barak Korren commented on OVIRT-869:


The error seems to be a DNS error:
{code}
DEBUG util.py:421:  
http://proxy.phx.ovirt.org:5000/centos-base/7/x86_64/Packages/unzip-6.0-15.el7.x86_64.rpm:
 [Errno 14] curl#5 - "Could not resolve proxy: proxy.phx.ovirt.org"
{code}

Port 5000 is where the python script is running no? So the Squid had an issue 
resolving the name of the very host it is running on? We should probably just 
resolve this forever by placing the name in {{/etc/hosts}} on the proxy 
server

{code}
Either use original repos if proxy is down or add watchdog / alerts for the 
proxy service.
{code}
We have this:
# {{mock_runner.sh}} tries to contact proxy and uses un-proxyed configuration 
if it fails (This is why it has both {{\*.cnf}} and {{*-proxy.cnf}} files)
# There is a cron job watchdog running on the proxy itself and restarting it
# AFAIK we also have Icinga monitoring it.

Typically the failures we're seeing are because of failures in the origin 
mirror we are actually proxying (Fedora and EPEL seem to be notoriously 
non-atomic when updating their mirrors). The way to solve this is only to used 
fully-fledged mirrors instead of a proxy (But this takes more maintenance and 
more storage). 


> Investigate proxy errors from proxy.phx.ovirt.org
> -
>
> Key: OVIRT-869
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-869
> Project: oVirt - virtualization made easy
>  Issue Type: Bug
>Reporter: eyal edri [Administrator]
>Assignee: infra
>Priority: Highest
>
> We need to make sure jobs don't fail on proxy like [1].
> Either use original repos if proxy is down or add watchdog / alerts for the 
> proxy service.
> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3693/artifact/exported-artifacts/basic_suite_master.sh-el7/logs/mocker-epel-7-x86_64.el7.init/root.log



--
This message was sent by Atlassian JIRA
(v1000.571.2#100021)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Build failed in Jenkins: ovirt_3.6_he-system-tests #734

[jenkins]

See 

Changes:

[Eyal Edri] adding missing python-simplejson to epel repo

--
[...truncated 874 lines...]
##  took 1345 seconds
##  rc = 1
##
##! ERROR v
##! Last 20 log entries: 
logs/mocker-epel-7-x86_64.el7.he_basic_suite_3.6.sh/he_basic_suite_3.6.sh.log
##!
+ env_cleanup
+ echo '#'
#
+ local res=0
+ local uuid
+ echo ' Cleaning up'
 Cleaning up
+ [[ -e 

 ]]
+ echo '--- Cleaning with lago'
--- Cleaning with lago
+ lago --workdir 

 destroy --yes --all-prefixes
+ echo '--- Cleaning with lago done'
--- Cleaning with lago done
+ [[ 0 != \0 ]]
+ echo ' Cleanup done'
 Cleanup done
+ exit 0
+ exit
Took 1204 seconds
===
##!
##! ERROR ^^
##!
##
Build step 'Execute shell' marked build as failure
Performing Post build task...
Match found for :.* : True
Logical operation result is TRUE
Running script  : #!/bin/bash -xe
echo 'shell_scripts/system_tests.collect_logs.sh'

#
# Required jjb vars:
#version
#
VERSION=3.6
SUITE_TYPE=

WORKSPACE="$PWD"
OVIRT_SUITE="$SUITE_TYPE_suite_$VERSION"
TESTS_LOGS="$WORKSPACE/ovirt-system-tests/exported-artifacts"

rm -rf "$WORKSPACE/exported-artifacts"
mkdir -p "$WORKSPACE/exported-artifacts"

if [[ -d "$TESTS_LOGS" ]]; then
mv "$TESTS_LOGS/"* "$WORKSPACE/exported-artifacts/"
fi

[ovirt_3.6_he-system-tests] $ /bin/bash -xe /tmp/hudson4013391311264500255.sh
+ echo shell_scripts/system_tests.collect_logs.sh
shell_scripts/system_tests.collect_logs.sh
+ VERSION=3.6
+ SUITE_TYPE=
+ WORKSPACE=
+ OVIRT_SUITE=3.6
+ 
TESTS_LOGS=
+ rm -rf 

+ mkdir -p 

+ [[ -d 

 ]]
+ mv 

 

POST BUILD TASK : SUCCESS
END OF POST BUILD TASK : 0
Match found for :.* : True
Logical operation result is TRUE
Running script  : #!/bin/bash -xe
echo "shell-scripts/mock_cleanup.sh"

shopt -s nullglob


WORKSPACE="$PWD"

# Make clear this is the cleanup, helps reading the jenkins logs
cat 
+ cat
___
###
# #
#   CLEANUP   #
# #
###
+ logs=(./*log ./*/logs)
+ [[ -n ./ovirt-system-tests/logs ]]
+ for log in '"${logs[@]}"'
+ echo 'Copying ./ovirt-system-tests/logs to exported-artifacts'
Copying ./ovirt-system-tests/logs to exported-artifacts
+ mv ./ovirt-system-tests/logs exported-artifacts/
+ failed=false
+ mock_confs=("$WORKSPACE"/*/mocker*)
+ for mock_conf_file in '"${mock_confs[@]}"'
+ [[ -n 

 ]]
+ echo 'Cleaning up mock '
Cleaning up mock 
+ mock_root=mocker-epel-7-x86_64.el7.cfg
+ mock_root=mocker-epel-7-x86_64.el7
+ my_mock=/usr/bin/mock
+ my_mock+=' 
--configdir=
+ my_mock+=' --root=mocker-epel-7-x86_64.el7'
+ my_mock+=' 
--resultdir=
+ echo 'Killing all mock orphan processes, if any.'
Killing all mock orphan processes, if any.
+ /usr/bin/mock 
--configdir=
 --root=mocker-epel-7-x86_64.el7 
--resultdir= 
--orphanskill
WARNING: Could not find required logging config file: