- Infra - oVirt List Archives

[JIRA] (OVIRT-919) Fwd: CI slaves extremely slow - overloaded slaves?
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-919?page=com.atlassian.jira.p… ] Barak Korren commented on OVIRT-919: ------------------------------------ {quote} ... snip ... 17:19:49 1.105877 seconds This test runs in 0.048 seconds on my laptop: ... snip ... Ran 4 tests in 0.189s {quote} [~nsoffer(a)redhat.com] Lets make sure we're comparing apples and apples first, did you run this using "{{mock_runner.sh}}" on your laptop? Perhaps try this in a VM on your laptop? {quote} It seems that we are overloading the CI slaves. We should not use nested kvm for the CI, such vms are much slower then regular vms, and we probably run too many vms per cpu. {quote} Not sure where nested kvm comes into play here, "{{check_patch.sh}}" runs on plain VMs. (As an OT side-note: Are you sure nested VMs should be slower CPU-wise? AFAIK those are just VMs with nested I/O routing... it may be interesting to check this with Lago...) WRT "overloaded slaves" - that can hardly happen, no slave ever runs more then one job at at time. The hypervisors themselves may be loaded, we'll try to gather some more data here: [~ngoldin(a)redhat.com] Do we have hypervisor load graphs in Graphite? [~ederevea] What is out vm/core ratio? Are we running oVirt DWH? maybe it can help us here... {quote} We can disable such tests in the CI, but we do want to know when there is a regression in this code. Before it was fixed, the same test took 9 seconds on my laptop. We need fast machines in the CI for this. {quote} As far as machines go, our upstream hardware is quite beefy these days, so lets not jump to any conclusions. More data is needed, what is this test actually doing? is this pure CPU, or is there so I/O involved here as well? [~rgolan(a)redhat.com] Are there any oVirt features that can help us here? Higher priority VMs? Realtime? Better scheduling? > Fwd: CI slaves extremely slow - overloaded slaves? > -------------------------------------------------- > > Key: OVIRT-919 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-919 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > Labels: hypervisors, performance, slaves, standard-ci > > From: Nir Soffer <nsoffer(a)redhat.com> > Date: 7 December 2016 at 21:33 > Subject: CI slaves extremely slow - overloaded slaves? > To: infra <infra(a)ovirt.org>, Eyal Edri <eedri(a)redhat.com>, Dan > Kenigsberg <danken(a)redhat.com> > Hi all, > In the last weeks we see more and more test failures due to timeouts in the CI. > For example: > 17:19:49 ====================================================================== > 17:19:49 FAIL: test_scale (storage_filesd_test.GetAllVolumesTests) > 17:19:49 ---------------------------------------------------------------------- > 17:19:49 Traceback (most recent call last): > 17:19:49 File > "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/storage_filesd_test.py", > line 165, in test_scale > 17:19:49 self.assertTrue(elapsed < 1.0, "Elapsed time: %f seconds" > % elapsed) > 17:19:49 AssertionError: Elapsed time: 1.105877 seconds > 17:19:49 -------------------- >> begin captured stdout << --------------------- > 17:19:49 1.105877 seconds > This test runs in 0.048 seconds on my laptop: > $ ./run_tests_local.sh storage_filesd_test.py -s > nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] > storage_filesd_test.GetAllVolumesTests > test_no_templates OK > test_no_volumes OK > test_scale 0.047932 seconds > OK > test_with_template OK > ---------------------------------------------------------------------- > Ran 4 tests in 0.189s > It seems that we are overloading the CI slaves. We should not use nested kvm > for the CI, such vms are much slower then regular vms, and we probably run > too many vms per cpu. > We can disable such tests in the CI, but we do want to know when there is > a regression in this code. Before it was fixed, the same test took 9 seconds > on my laptop. We need fast machines in the CI for this. > Nir -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-919) Fwd: CI slaves extremely slow - overloaded slaves?
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-919?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-919: ------------------------------- Labels: hypervisors performance slaves standard-ci (was: ) > Fwd: CI slaves extremely slow - overloaded slaves? > -------------------------------------------------- > > Key: OVIRT-919 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-919 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > Labels: hypervisors, performance, slaves, standard-ci > > From: Nir Soffer <nsoffer(a)redhat.com> > Date: 7 December 2016 at 21:33 > Subject: CI slaves extremely slow - overloaded slaves? > To: infra <infra(a)ovirt.org>, Eyal Edri <eedri(a)redhat.com>, Dan > Kenigsberg <danken(a)redhat.com> > Hi all, > In the last weeks we see more and more test failures due to timeouts in the CI. > For example: > 17:19:49 ====================================================================== > 17:19:49 FAIL: test_scale (storage_filesd_test.GetAllVolumesTests) > 17:19:49 ---------------------------------------------------------------------- > 17:19:49 Traceback (most recent call last): > 17:19:49 File > "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/storage_filesd_test.py", > line 165, in test_scale > 17:19:49 self.assertTrue(elapsed < 1.0, "Elapsed time: %f seconds" > % elapsed) > 17:19:49 AssertionError: Elapsed time: 1.105877 seconds > 17:19:49 -------------------- >> begin captured stdout << --------------------- > 17:19:49 1.105877 seconds > This test runs in 0.048 seconds on my laptop: > $ ./run_tests_local.sh storage_filesd_test.py -s > nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] > storage_filesd_test.GetAllVolumesTests > test_no_templates OK > test_no_volumes OK > test_scale 0.047932 seconds > OK > test_with_template OK > ---------------------------------------------------------------------- > Ran 4 tests in 0.189s > It seems that we are overloading the CI slaves. We should not use nested kvm > for the CI, such vms are much slower then regular vms, and we probably run > too many vms per cpu. > We can disable such tests in the CI, but we do want to know when there is > a regression in this code. Before it was fixed, the same test took 9 seconds > on my laptop. We need fast machines in the CI for this. > Nir -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-919) Fwd: CI slaves extremely slow - overloaded slaves?
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-919?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-919: ------------------------------- Component/s: Jenkins > Fwd: CI slaves extremely slow - overloaded slaves? > -------------------------------------------------- > > Key: OVIRT-919 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-919 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > > From: Nir Soffer <nsoffer(a)redhat.com> > Date: 7 December 2016 at 21:33 > Subject: CI slaves extremely slow - overloaded slaves? > To: infra <infra(a)ovirt.org>, Eyal Edri <eedri(a)redhat.com>, Dan > Kenigsberg <danken(a)redhat.com> > Hi all, > In the last weeks we see more and more test failures due to timeouts in the CI. > For example: > 17:19:49 ====================================================================== > 17:19:49 FAIL: test_scale (storage_filesd_test.GetAllVolumesTests) > 17:19:49 ---------------------------------------------------------------------- > 17:19:49 Traceback (most recent call last): > 17:19:49 File > "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/storage_filesd_test.py", > line 165, in test_scale > 17:19:49 self.assertTrue(elapsed < 1.0, "Elapsed time: %f seconds" > % elapsed) > 17:19:49 AssertionError: Elapsed time: 1.105877 seconds > 17:19:49 -------------------- >> begin captured stdout << --------------------- > 17:19:49 1.105877 seconds > This test runs in 0.048 seconds on my laptop: > $ ./run_tests_local.sh storage_filesd_test.py -s > nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] > storage_filesd_test.GetAllVolumesTests > test_no_templates OK > test_no_volumes OK > test_scale 0.047932 seconds > OK > test_with_template OK > ---------------------------------------------------------------------- > Ran 4 tests in 0.189s > It seems that we are overloading the CI slaves. We should not use nested kvm > for the CI, such vms are much slower then regular vms, and we probably run > too many vms per cpu. > We can disable such tests in the CI, but we do want to know when there is > a regression in this code. Before it was fixed, the same test took 9 seconds > on my laptop. We need fast machines in the CI for this. > Nir -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

CI slaves extremely slow - overloaded slaves?
by Nir Soffer 08 Dec '16

08 Dec '16

Hi all, In the last weeks we see more and more test failures due to timeouts in the CI. For example: 17:19:49 ====================================================================== 17:19:49 FAIL: test_scale (storage_filesd_test.GetAllVolumesTests) 17:19:49 ---------------------------------------------------------------------- 17:19:49 Traceback (most recent call last): 17:19:49 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/storage_filesd_test.py", line 165, in test_scale 17:19:49 self.assertTrue(elapsed < 1.0, "Elapsed time: %f seconds" % elapsed) 17:19:49 AssertionError: Elapsed time: 1.105877 seconds 17:19:49 -------------------- >> begin captured stdout << --------------------- 17:19:49 1.105877 seconds This test runs in 0.048 seconds on my laptop: $ ./run_tests_local.sh storage_filesd_test.py -s nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] storage_filesd_test.GetAllVolumesTests test_no_templates OK test_no_volumes OK test_scale 0.047932 seconds OK test_with_template OK ---------------------------------------------------------------------- Ran 4 tests in 0.189s It seems that we are overloading the CI slaves. We should not use nested kvm for the CI, such vms are much slower then regular vms, and we probably run too many vms per cpu. We can disable such tests in the CI, but we do want to know when there is a regression in this code. Before it was fixed, the same test took 9 seconds on my laptop. We need fast machines in the CI for this. Nir

2 1

[JIRA] (OVIRT-919) Fwd: CI slaves extremely slow - overloaded slaves?
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-919?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-919: ------------------------------- Description: From: Nir Soffer <nsoffer(a)redhat.com> Date: 7 December 2016 at 21:33 Subject: CI slaves extremely slow - overloaded slaves? To: infra <infra(a)ovirt.org>, Eyal Edri <eedri(a)redhat.com>, Dan Kenigsberg <danken(a)redhat.com> Hi all, In the last weeks we see more and more test failures due to timeouts in the CI. For example: 17:19:49 ====================================================================== 17:19:49 FAIL: test_scale (storage_filesd_test.GetAllVolumesTests) 17:19:49 ---------------------------------------------------------------------- 17:19:49 Traceback (most recent call last): 17:19:49 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/storage_filesd_test.py", line 165, in test_scale 17:19:49 self.assertTrue(elapsed < 1.0, "Elapsed time: %f seconds" % elapsed) 17:19:49 AssertionError: Elapsed time: 1.105877 seconds 17:19:49 -------------------- >> begin captured stdout << --------------------- 17:19:49 1.105877 seconds This test runs in 0.048 seconds on my laptop: $ ./run_tests_local.sh storage_filesd_test.py -s nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] storage_filesd_test.GetAllVolumesTests test_no_templates OK test_no_volumes OK test_scale 0.047932 seconds OK test_with_template OK ---------------------------------------------------------------------- Ran 4 tests in 0.189s It seems that we are overloading the CI slaves. We should not use nested kvm for the CI, such vms are much slower then regular vms, and we probably run too many vms per cpu. We can disable such tests in the CI, but we do want to know when there is a regression in this code. Before it was fixed, the same test took 9 seconds on my laptop. We need fast machines in the CI for this. Nir _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra -- Barak Korren bkorren(a)redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ was: More discussion and tracking needed, moving to Jira (please put any further discussion there) ---------- Forwarded message ---------- From: Nir Soffer <nsoffer(a)redhat.com> Date: 7 December 2016 at 21:33 Subject: CI slaves extremely slow - overloaded slaves? To: infra <infra(a)ovirt.org>, Eyal Edri <eedri(a)redhat.com>, Dan Kenigsberg <danken(a)redhat.com> Hi all, In the last weeks we see more and more test failures due to timeouts in the CI. For example: 17:19:49 ====================================================================== 17:19:49 FAIL: test_scale (storage_filesd_test.GetAllVolumesTests) 17:19:49 ---------------------------------------------------------------------- 17:19:49 Traceback (most recent call last): 17:19:49 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/storage_filesd_test.py", line 165, in test_scale 17:19:49 self.assertTrue(elapsed < 1.0, "Elapsed time: %f seconds" % elapsed) 17:19:49 AssertionError: Elapsed time: 1.105877 seconds 17:19:49 -------------------- >> begin captured stdout << --------------------- 17:19:49 1.105877 seconds This test runs in 0.048 seconds on my laptop: $ ./run_tests_local.sh storage_filesd_test.py -s nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] storage_filesd_test.GetAllVolumesTests test_no_templates OK test_no_volumes OK test_scale 0.047932 seconds OK test_with_template OK ---------------------------------------------------------------------- Ran 4 tests in 0.189s It seems that we are overloading the CI slaves. We should not use nested kvm for the CI, such vms are much slower then regular vms, and we probably run too many vms per cpu. We can disable such tests in the CI, but we do want to know when there is a regression in this code. Before it was fixed, the same test took 9 seconds on my laptop. We need fast machines in the CI for this. Nir _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra -- Barak Korren bkorren(a)redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ > Fwd: CI slaves extremely slow - overloaded slaves? > -------------------------------------------------- > > Key: OVIRT-919 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-919 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Barak Korren > Assignee: infra > > From: Nir Soffer <nsoffer(a)redhat.com> > Date: 7 December 2016 at 21:33 > Subject: CI slaves extremely slow - overloaded slaves? > To: infra <infra(a)ovirt.org>, Eyal Edri <eedri(a)redhat.com>, Dan > Kenigsberg <danken(a)redhat.com> > Hi all, > In the last weeks we see more and more test failures due to timeouts in the CI. > For example: > 17:19:49 ====================================================================== > 17:19:49 FAIL: test_scale (storage_filesd_test.GetAllVolumesTests) > 17:19:49 ---------------------------------------------------------------------- > 17:19:49 Traceback (most recent call last): > 17:19:49 File > "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/storage_filesd_test.py", > line 165, in test_scale > 17:19:49 self.assertTrue(elapsed < 1.0, "Elapsed time: %f seconds" > % elapsed) > 17:19:49 AssertionError: Elapsed time: 1.105877 seconds > 17:19:49 -------------------- >> begin captured stdout << --------------------- > 17:19:49 1.105877 seconds > This test runs in 0.048 seconds on my laptop: > $ ./run_tests_local.sh storage_filesd_test.py -s > nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] > storage_filesd_test.GetAllVolumesTests > test_no_templates OK > test_no_volumes OK > test_scale 0.047932 seconds > OK > test_with_template OK > ---------------------------------------------------------------------- > Ran 4 tests in 0.189s > It seems that we are overloading the CI slaves. We should not use nested kvm > for the CI, such vms are much slower then regular vms, and we probably run > too many vms per cpu. > We can disable such tests in the CI, but we do want to know when there is > a regression in this code. Before it was fixed, the same test took 9 seconds > on my laptop. We need fast machines in the CI for this. > Nir > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra > -- > Barak Korren > bkorren(a)redhat.com > RHCE, RHCi, RHV-DevOps Team > https://ifireball.wordpress.com/ -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-919) Fwd: CI slaves extremely slow - overloaded slaves?
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-919?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-919: ------------------------------- Description: From: Nir Soffer <nsoffer(a)redhat.com> Date: 7 December 2016 at 21:33 Subject: CI slaves extremely slow - overloaded slaves? To: infra <infra(a)ovirt.org>, Eyal Edri <eedri(a)redhat.com>, Dan Kenigsberg <danken(a)redhat.com> Hi all, In the last weeks we see more and more test failures due to timeouts in the CI. For example: 17:19:49 ====================================================================== 17:19:49 FAIL: test_scale (storage_filesd_test.GetAllVolumesTests) 17:19:49 ---------------------------------------------------------------------- 17:19:49 Traceback (most recent call last): 17:19:49 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/storage_filesd_test.py", line 165, in test_scale 17:19:49 self.assertTrue(elapsed < 1.0, "Elapsed time: %f seconds" % elapsed) 17:19:49 AssertionError: Elapsed time: 1.105877 seconds 17:19:49 -------------------- >> begin captured stdout << --------------------- 17:19:49 1.105877 seconds This test runs in 0.048 seconds on my laptop: $ ./run_tests_local.sh storage_filesd_test.py -s nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] storage_filesd_test.GetAllVolumesTests test_no_templates OK test_no_volumes OK test_scale 0.047932 seconds OK test_with_template OK ---------------------------------------------------------------------- Ran 4 tests in 0.189s It seems that we are overloading the CI slaves. We should not use nested kvm for the CI, such vms are much slower then regular vms, and we probably run too many vms per cpu. We can disable such tests in the CI, but we do want to know when there is a regression in this code. Before it was fixed, the same test took 9 seconds on my laptop. We need fast machines in the CI for this. Nir was: From: Nir Soffer <nsoffer(a)redhat.com> Date: 7 December 2016 at 21:33 Subject: CI slaves extremely slow - overloaded slaves? To: infra <infra(a)ovirt.org>, Eyal Edri <eedri(a)redhat.com>, Dan Kenigsberg <danken(a)redhat.com> Hi all, In the last weeks we see more and more test failures due to timeouts in the CI. For example: 17:19:49 ====================================================================== 17:19:49 FAIL: test_scale (storage_filesd_test.GetAllVolumesTests) 17:19:49 ---------------------------------------------------------------------- 17:19:49 Traceback (most recent call last): 17:19:49 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/storage_filesd_test.py", line 165, in test_scale 17:19:49 self.assertTrue(elapsed < 1.0, "Elapsed time: %f seconds" % elapsed) 17:19:49 AssertionError: Elapsed time: 1.105877 seconds 17:19:49 -------------------- >> begin captured stdout << --------------------- 17:19:49 1.105877 seconds This test runs in 0.048 seconds on my laptop: $ ./run_tests_local.sh storage_filesd_test.py -s nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] storage_filesd_test.GetAllVolumesTests test_no_templates OK test_no_volumes OK test_scale 0.047932 seconds OK test_with_template OK ---------------------------------------------------------------------- Ran 4 tests in 0.189s It seems that we are overloading the CI slaves. We should not use nested kvm for the CI, such vms are much slower then regular vms, and we probably run too many vms per cpu. We can disable such tests in the CI, but we do want to know when there is a regression in this code. Before it was fixed, the same test took 9 seconds on my laptop. We need fast machines in the CI for this. Nir _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra -- Barak Korren bkorren(a)redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ > Fwd: CI slaves extremely slow - overloaded slaves? > -------------------------------------------------- > > Key: OVIRT-919 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-919 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Barak Korren > Assignee: infra > > From: Nir Soffer <nsoffer(a)redhat.com> > Date: 7 December 2016 at 21:33 > Subject: CI slaves extremely slow - overloaded slaves? > To: infra <infra(a)ovirt.org>, Eyal Edri <eedri(a)redhat.com>, Dan > Kenigsberg <danken(a)redhat.com> > Hi all, > In the last weeks we see more and more test failures due to timeouts in the CI. > For example: > 17:19:49 ====================================================================== > 17:19:49 FAIL: test_scale (storage_filesd_test.GetAllVolumesTests) > 17:19:49 ---------------------------------------------------------------------- > 17:19:49 Traceback (most recent call last): > 17:19:49 File > "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/storage_filesd_test.py", > line 165, in test_scale > 17:19:49 self.assertTrue(elapsed < 1.0, "Elapsed time: %f seconds" > % elapsed) > 17:19:49 AssertionError: Elapsed time: 1.105877 seconds > 17:19:49 -------------------- >> begin captured stdout << --------------------- > 17:19:49 1.105877 seconds > This test runs in 0.048 seconds on my laptop: > $ ./run_tests_local.sh storage_filesd_test.py -s > nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] > storage_filesd_test.GetAllVolumesTests > test_no_templates OK > test_no_volumes OK > test_scale 0.047932 seconds > OK > test_with_template OK > ---------------------------------------------------------------------- > Ran 4 tests in 0.189s > It seems that we are overloading the CI slaves. We should not use nested kvm > for the CI, such vms are much slower then regular vms, and we probably run > too many vms per cpu. > We can disable such tests in the CI, but we do want to know when there is > a regression in this code. Before it was fixed, the same test took 9 seconds > on my laptop. We need fast machines in the CI for this. > Nir -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-919) Fwd: CI slaves extremely slow - overloaded slaves?
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

Barak Korren created OVIRT-919: ---------------------------------- Summary: Fwd: CI slaves extremely slow - overloaded slaves? Key: OVIRT-919 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-919 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Barak Korren Assignee: infra More discussion and tracking needed, moving to Jira (please put any further discussion there) ---------- Forwarded message ---------- From: Nir Soffer <nsoffer(a)redhat.com> Date: 7 December 2016 at 21:33 Subject: CI slaves extremely slow - overloaded slaves? To: infra <infra(a)ovirt.org>, Eyal Edri <eedri(a)redhat.com>, Dan Kenigsberg <danken(a)redhat.com> Hi all, In the last weeks we see more and more test failures due to timeouts in the CI. For example: 17:19:49 ====================================================================== 17:19:49 FAIL: test_scale (storage_filesd_test.GetAllVolumesTests) 17:19:49 ---------------------------------------------------------------------- 17:19:49 Traceback (most recent call last): 17:19:49 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/storage_filesd_test.py", line 165, in test_scale 17:19:49 self.assertTrue(elapsed < 1.0, "Elapsed time: %f seconds" % elapsed) 17:19:49 AssertionError: Elapsed time: 1.105877 seconds 17:19:49 -------------------- >> begin captured stdout << --------------------- 17:19:49 1.105877 seconds This test runs in 0.048 seconds on my laptop: $ ./run_tests_local.sh storage_filesd_test.py -s nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] storage_filesd_test.GetAllVolumesTests test_no_templates OK test_no_volumes OK test_scale 0.047932 seconds OK test_with_template OK ---------------------------------------------------------------------- Ran 4 tests in 0.189s It seems that we are overloading the CI slaves. We should not use nested kvm for the CI, such vms are much slower then regular vms, and we probably run too many vms per cpu. We can disable such tests in the CI, but we do want to know when there is a regression in this code. Before it was fixed, the same test took 9 seconds on my laptop. We need fast machines in the CI for this. Nir _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra -- Barak Korren bkorren(a)redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-918) Special characters escaped in Jenkins manual triggering of CI
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-918?page=com.atlassian.jira.p… ] Barak Korren commented on OVIRT-918: ------------------------------------ That is not a job, its a special screen that is part of the [Gerrit trigger plugin|https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger] We do seem to be a couple releases behind (2.21.1) the latest plugin release (2.23.0). So we may upgrade, but nothing in the plugin changelog implies that this issue was dealt with. We may as well just go and report this on the [Jenkins issue tracker|http://issues.jenkins-ci.org/secure/IssueNavigator.jspa?mode=hide&r…] > Special characters escaped in Jenkins manual triggering of CI > ------------------------------------------------------------- > > Key: OVIRT-918 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-918 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Jenkins > Reporter: Allon Mureinik > Assignee: infra > > If a subject of a change has special characters, they get HTML-encoded when presenting it in the Jenkins manual trigger job. > See screenshot for an example: > http://imgur.com/G1M7vNu -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

oVirt infra daily report - unstable production jobs - 161
by jenkins＠jenkins.phx.ovirt.org 08 Dec '16

08 Dec '16

------=_Part_41_1154478995.1481151609825 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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/161//artifact/exported-a… Cheers, Jenkins ------=_Part_41_1154478995.1481151609825 Content-Type: text/html; charset=us-ascii; name=upstream_report.html Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=upstream_report.html Content-ID: <upstream_report.html> <!DOCTYPE html><head><style type="text/css"> table.gridtable { border-collapse: collapse; table-layout:fixed; width:1600px; font-family: monospace; font-size:13px; } .head { font-size:20px; font-family: arial; } .sub { font-size:18px; background-color:#e5e5e5; font-family: arial; } pre { font-family: monospace; display: inline; white-space: pre-wrap; white-space: -moz-pre-wrap !important; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word; } </style> </head> <body> <table class="gridtable" border=2> <tr><th colspan=2 class=head> RHEVM CI Jenkins Daily Report - 07/12/2016 </th></tr><tr><th colspan=2 class=sub> <font color="blue"><a href="http://jenkins.ovirt.org/">00 Unstable Jobs (Production)</a></font> </th></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/cockpit-ovirt_ovirt-4.1_build-artifacts-fc23-x…">cockpit-ovirt_ovirt-4.1_build-artifacts-fc23-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/fabric-ovirt_master_check-merged-el7-x86_64/">fabric-ovirt_master_check-merged-el7-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-engine-api-explorer_master_build-artifac…">ovirt-engine-api-explorer_master_build-artifacts-fc23-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-guest-agent_master_build-artifacts-el6-x…">ovirt-guest-agent_master_build-artifacts-el6-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-guest-agent_master_build-artifacts-fc23-…">ovirt-guest-agent_master_build-artifacts-fc23-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-hosted-engine-ha_master_build-artifacts-…">ovirt-hosted-engine-ha_master_build-artifacts-fc24-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-live_master_experimental_create-iso-el7-…">ovirt-live_master_experimental_create-iso-el7-x86_64</a> </td><td> <h3>This job generates a nightly iso of ovirt-live using experimental repos</h3> </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-node-ng_master_build-artifacts-el7-x86_6…">ovirt-node-ng_master_build-artifacts-el7-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-3.6_build-artifacts-el7-x8…">ovirt-node-ng_ovirt-3.6_build-artifacts-el7-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-4.0_build-artifacts-el7-x8…">ovirt-node-ng_ovirt-4.0_build-artifacts-el7-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-4.1-pre_build-artifacts-el…">ovirt-node-ng_ovirt-4.1-pre_build-artifacts-el7-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-master-experimental_build-…">ovirt-node-ng_ovirt-master-experimental_build-artifacts-el7-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-node_ovirt-3.6_create-iso-el7_merged/">ovirt-node_ovirt-3.6_create-iso-el7_merged</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-optimizer_4.0_build-artifacts-el6-x86_64/">ovirt-optimizer_4.0_build-artifacts-el6-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt_3.6_he-system-tests/">ovirt_3.6_he-system-tests</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/repos_master_check-closure_fc24_merged/">repos_master_check-closure_fc24_merged</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/vdsm_4.0_check-merged-fc23-x86_64/">vdsm_4.0_check-merged-fc23-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> ------=_Part_41_1154478995.1481151609825--

1 0

[oVirt Jenkins] test-repo_ovirt_experimental_3.6 - Build #4322 - FAILURE!
by jenkins＠jenkins.phx.ovirt.org 07 Dec '16

07 Dec '16

------=_Part_37_255403216.1481135748279 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_3.6/4322/, Build Number: 4322, Build Status: FAILURE ------=_Part_37_255403216.1481135748279--

1 1

[JIRA] (OVIRT-918) Special characters escaped in Jenkins manual triggering of CI
by Allon Mureinik (oVirt JIRA) 07 Dec '16

07 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-918?page=com.atlassian.jira.p… ] Allon Mureinik updated OVIRT-918: --------------------------------- Epic Link: OVIRT-400 > Special characters escaped in Jenkins manual triggering of CI > ------------------------------------------------------------- > > Key: OVIRT-918 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-918 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Jenkins > Reporter: Allon Mureinik > Assignee: infra > > If a subject of a change has special characters, they get HTML-encoded when presenting it in the Jenkins manual trigger job. > See screenshot for an example: > http://imgur.com/G1M7vNu -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-918) Special characters escaped in Jenkins manual triggering of CI
by Allon Mureinik (oVirt JIRA) 07 Dec '16

07 Dec '16

Allon Mureinik created OVIRT-918: ------------------------------------ Summary: Special characters escaped in Jenkins manual triggering of CI Key: OVIRT-918 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-918 Project: oVirt - virtualization made easy Issue Type: Bug Components: Jenkins Reporter: Allon Mureinik Assignee: infra If a subject of a change has special characters, they get HTML-encoded when presenting it in the Jenkins manual trigger job. See screenshot for an example: http://imgur.com/G1M7vNu -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-917) Investigate creating "permalinks" for ML messages
by Barak Korren (oVirt JIRA) 07 Dec '16

07 Dec '16

Barak Korren created OVIRT-917: ---------------------------------- Summary: Investigate creating "permalinks" for ML messages Key: OVIRT-917 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-917 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Mailing lists (Mailman) Reporter: Barak Korren Assignee: infra This is so messages and threads could be linked to from other messages, blogs, etc. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-917) Investigate creating "permalinks" for ML messages
by Barak Korren (oVirt JIRA) 07 Dec '16

07 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-917?page=com.atlassian.jira.p… ] Barak Korren reassigned OVIRT-917: ---------------------------------- Assignee: Marc Dequènes (Duck) (was: infra) > Investigate creating "permalinks" for ML messages > ------------------------------------------------- > > Key: OVIRT-917 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-917 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Mailing lists (Mailman) > Reporter: Barak Korren > Assignee: Marc Dequènes (Duck) > > This is so messages and threads could be linked to from other messages, blogs, etc. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-917) Investigate creating "permalinks" for ML messages
by Barak Korren (oVirt JIRA) 07 Dec '16

07 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-917?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-917: ------------------------------- Epic Link: OVIRT-403 > Investigate creating "permalinks" for ML messages > ------------------------------------------------- > > Key: OVIRT-917 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-917 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Mailing lists (Mailman) > Reporter: Barak Korren > Assignee: infra > > This is so messages and threads could be linked to from other messages, blogs, etc. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

Vdsm tests are 4X times faster on travis
by Nir Soffer 07 Dec '16

07 Dec '16

HI all, Watching vdsm travis builds in the last weeks, it is clear that vdsm tests on travis are about 4X times faster compared with jenkins builds. Here is a typical build: ovirt ci: http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/5101/conso… travis ci: https://travis-ci.org/nirs/vdsm/builds/179056079 The build took 4:34 on travis, and 19:34 on ovirt ci. This has a huge impact on vdsm maintainers. Having to wait 20 minutes for each patch means that we must ignore the ci and merge and hope that previous tests without rebasing on master were good enough. The builds are mostly the same, expect: - In travis we don't check if the build system was changed and packages should be built takes 9:18 minutes in ovirt ci. - In travis we don't clean or install anything before the test, we use a container with all the available packages, pulled from dockerhub. takes about 3:52 minutes in ovirt ci - In travis we don't enable coverage. Running the tests with coverage may slow down the tests takes 5:04 minutes in ovirt ci creating the coverage report takes only 15 seconds, not interesting - In travis we don't cleanup anything after the test this takes 34 seconds in ovirt ci The biggest problem is the build system check taking 9:18 minutes. fixing it will cut the build time in half. This is how time is spent in ovirt ci: 1. Starting (1:28) 00:00:00.001 Triggered by Gerrit: https://gerrit.ovirt.org/67338 00:00:00.039 [EnvInject] - Loading node environment variables. 00:00:00.056 Building remotely on fc24-vm15.phx.ovirt.org (phx nested local_disk fc24) in workspace /home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64 2. Installing packages (2:24) 00:01:28.338 INFO: installing package(s): autoconf automake gdb git libguestfs-tools-c libselinux-python3 libvirt-python3 m2crypto make mom openvswitch policycoreutils-python PyYAML python-blivet python-coverage python2-decorator python-devel python-inotify python-ioprocess python-mock python-netaddr python-pthreading python-setuptools python-six python-requests python3-decorator python3-netaddr python3-nose python3-six python3-yaml rpm-build sanlock-python sudo yum yum-utils 3. Setup in check-patch.sh (00:04) 00:03:52.838 + export VDSM_AUTOMATION=1 4. Running the actual tests 00:03:56.670 + ./autogen.sh --system --enable-hooks --enable-vhostmd 5. Installing python-debugifo (00:19) 00:04:15.385 Yum-utils package has been deprecated, use dnf instead. 6. Running make check (05:04) 00:04:30.948 + TIMEOUT=600 00:04:30.948 + make check NOSE_WITH_COVERAGE=1 NOSE_COVER_PACKAGE=/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/vdsm,/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib ... 00:09:33.981 tests: commands succeeded 00:09:33.981 congratulations :) 7. Creating coverage report (00:15) 00:09:34.017 + coverage html -d /home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/exported-artifacts/htmlcov 8. Finding modified files (09:18) 00:09:49.213 + git diff-tree --no-commit-id --name-only -r HEAD 00:09:49.213 + egrep --quiet 'vdsm.spec.in|Makefile.am' 9. Cleaing up (00:27) 00:19:07.994 Took 915 seconds 00:19:34.973 Finished: SUCCESS

3 13

Build failed in Jenkins: ovirt_4.0_system-tests #730
by jenkins＠jenkins.phx.ovirt.org 07 Dec '16

07 Dec '16

See <http://jenkins.ovirt.org/job/ovirt_4.0_system-tests/730/changes> Changes: [Yaniv Kaul] Temporarily move Master to 4.0 DC level. [Sandro Bonazzola] repo_closure_check: drop fc22 support [Barak Korren] Remove 'groupinstall' from mock config files ------------------------------------------ [...truncated 632 lines...] ## rc = 1 ########################################################## ##! ERROR vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv ##! Last 20 log entries: logs/mocker-epel-7-x86_64.el7.basic_suite_4.0.sh/basic_suite_4.0.sh.log ##! + env_cleanup + echo '#########################' ######################### + local res=0 + local uuid + echo '======== Cleaning up' ======== Cleaning up + [[ -e <http://jenkins.ovirt.org/job/ovirt_4.0_system-tests/ws/ovirt-system-tests/d…> ]] + echo '----------- Cleaning with lago' ----------- Cleaning with lago + lago --workdir <http://jenkins.ovirt.org/job/ovirt_4.0_system-tests/ws/ovirt-system-tests/d…> destroy --yes --all-prefixes + echo '----------- Cleaning with lago done' ----------- Cleaning with lago done + [[ 0 != \0 ]] + echo '======== Cleanup done' ======== Cleanup done + exit 0 + exit Took 231 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_system-tests] $ /bin/bash -xe /tmp/hudson1547577089412013445.sh + echo shell_scripts/system_tests.collect_logs.sh shell_scripts/system_tests.collect_logs.sh + VERSION=4.0 + SUITE_TYPE= + WORKSPACE=<http://jenkins.ovirt.org/job/ovirt_4.0_system-tests/ws/> + OVIRT_SUITE=4.0 + TESTS_LOGS=<http://jenkins.ovirt.org/job/ovirt_4.0_system-tests/ws/ovirt-system-tests/e…> + rm -rf <http://jenkins.ovirt.org/job/ovirt_4.0_system-tests/730/artifact/exported-a…> + mkdir -p <http://jenkins.ovirt.org/job/ovirt_4.0_system-tests/730/artifact/exported-a…> + [[ -d <http://jenkins.ovirt.org/job/ovirt_4.0_system-tests/ws/ovirt-system-tests/e…> ]] + mv <http://jenkins.ovirt.org/job/ovirt_4.0_system-tests/ws/ovirt-system-tests/e…> <http://jenkins.ovirt.org/job/ovirt_4.0_system-tests/730/artifact/exported-a…> 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 <<EOC _______________________________________________________________________ ####################################################################### # # # 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" mock_root="${mock_conf_file##*/}" mock_root="${mock_root%.*}" my_mock="/usr/bin/mock" my_mock+=" --configdir=${mock_conf_file%/*}" my_mock+=" --root=${mock_root}" my_mock+=" --resultdir=$WORKSPACE" #TODO: investigate why mock --clean fails to umount certain dirs sometimes, #so we can use it instead of manually doing all this. echo "Killing all mock orphan processes, if any." $my_mock \ --orphanskill \ || { echo "ERROR: Failed to kill orphans on $chroot." failed=true } mock_root="$(\ grep \ -Po "(?<=config_opts\['root'\] = ')[^']*" \ "$mock_conf_file" \ )" || : [[ "$mock_root" ]] || continue mounts=($(mount | awk '{print $3}' | grep "$mock_root")) || : if [[ "$mounts" ]]; then echo "Found mounted dirs inside the chroot $chroot. Trying to umount." fi for mount in "${mounts[@]}"; do sudo umount --lazy "$mount" \ || { echo "ERROR: Failed to umount $mount." failed=true } done done # Clean any leftover chroot from other jobs for mock_root in /var/lib/mock/*; do this_chroot_failed=false mounts=($(mount | awk '{print $3}' | grep "$mock_root")) || : if [[ "$mounts" ]]; then echo "Found mounted dirs inside the chroot $mock_root." \ "Trying to umount." fi for mount in "${mounts[@]}"; do sudo umount --lazy "$mount" \ || { echo "ERROR: Failed to umount $mount." failed=true this_chroot_failed=true } done if ! $this_chroot_failed; then sudo rm -rf "$mock_root" fi done if $failed; then echo "Aborting." exit 1 fi # remove mock caches that are older then 2 days: find /var/cache/mock/ -mindepth 1 -maxdepth 1 -type d -mtime +2 -print0 | \ xargs -0 -tr sudo rm -rf # We make no effort to leave around caches that may still be in use because # packages installed in them may go out of date, so may as well recreate them # restore the permissions in the working dir, as sometimes it leaves files # owned by root and then the 'cleanup workspace' from jenkins job fails to # clean and breaks the jobs sudo chown -R "$USER" "$WORKSPACE" # Drop all left over libvirt domains for UUID in $(virsh list --all --uuid); do virsh destroy $UUID || : sleep 2 virsh undefine --remove-all-storage --storage vda --snapshots-metadata $UUID || : done [ovirt_4.0_system-tests] $ /bin/bash -xe /tmp/hudson8638584986326842303.sh + echo shell-scripts/mock_cleanup.sh shell-scripts/mock_cleanup.sh + shopt -s nullglob + WORKSPACE=<http://jenkins.ovirt.org/job/ovirt_4.0_system-tests/ws/> + 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 <http://jenkins.ovirt.org/job/ovirt_4.0_system-tests/ws/ovirt-system-tests/m…> ]] + 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=<http://jenkins.ovirt.org/job/ovirt_4.0_system-tests/ws/ovirt-system-tests'> + my_mock+=' --root=mocker-epel-7-x86_64.el7' + my_mock+=' --resultdir=<http://jenkins.ovirt.org/job/ovirt_4.0_system-tests/ws/'> + echo 'Killing all mock orphan processes, if any.' Killing all mock orphan processes, if any. + /usr/bin/mock --configdir=<http://jenkins.ovirt.org/job/ovirt_4.0_system-tests/ws/ovirt-system-tests> --root=mocker-epel-7-x86_64.el7 --resultdir=<http://jenkins.ovirt.org/job/ovirt_4.0_system-tests/ws/> --orphanskill WARNING: Could not find required logging config file: <http://jenkins.ovirt.org/job/ovirt_4.0_system-tests/ws/ovirt-system-tests/l….> Using default... INFO: mock.py version 1.2.21 starting (python version = 3.4.3)... Start: init plugins INFO: selinux enabled Finish: init plugins Start: run Finish: run ++ grep -Po '(?<=config_opts\['\''root'\''\] = '\'')[^'\'']*' <http://jenkins.ovirt.org/job/ovirt_4.0_system-tests/ws/ovirt-system-tests/m…> + mock_root=epel-7-x86_64-ed452d1ea0f6dadf50c66d3b3f6b3a6e + [[ -n epel-7-x86_64-ed452d1ea0f6dadf50c66d3b3f6b3a6e ]] + mounts=($(mount | awk '{print $3}' | grep "$mock_root")) ++ mount ++ awk '{print $3}' ++ grep epel-7-x86_64-ed452d1ea0f6dadf50c66d3b3f6b3a6e + : + [[ -n '' ]] + false + find /var/cache/mock/ -mindepth 1 -maxdepth 1 -type d -mtime +2 -print0 + xargs -0 -tr sudo rm -rf + sudo chown -R jenkins <http://jenkins.ovirt.org/job/ovirt_4.0_system-tests/ws/> ++ virsh list --all --uuid POST BUILD TASK : SUCCESS END OF POST BUILD TASK : 1 Recording test results ERROR: Step ‘Publish JUnit test result report’ failed: No test report files were found. Configuration error? Archiving artifacts

1 1

Build failed in Jenkins: ovirt_4.0_he-system-tests #584
by jenkins＠jenkins.phx.ovirt.org 07 Dec '16

07 Dec '16

See <http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/584/changes> Changes: [Yaniv Kaul] Temporarily move Master to 4.0 DC level. [Sandro Bonazzola] repo_closure_check: drop fc22 support [Barak Korren] Remove 'groupinstall' from mock config files ------------------------------------------ [...truncated 664 lines...] ## rc = 127 ########################################################## ##! ERROR vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv ##! 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 <http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/ws/ovirt-system-test…> ]] + echo '----------- Cleaning with lago' ----------- Cleaning with lago + lago --workdir <http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/ws/ovirt-system-test…> destroy --yes --all-prefixes + echo '----------- Cleaning with lago done' ----------- Cleaning with lago done + [[ 0 != \0 ]] + echo '======== Cleanup done' ======== Cleanup done + exit 0 + exit Took 345 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/hudson15064946044288893.sh + echo shell_scripts/system_tests.collect_logs.sh shell_scripts/system_tests.collect_logs.sh + VERSION=4.0 + SUITE_TYPE= + WORKSPACE=<http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/ws/> + OVIRT_SUITE=4.0 + TESTS_LOGS=<http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/ws/ovirt-system-test…> + rm -rf <http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/584/artifact/exporte…> + mkdir -p <http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/584/artifact/exporte…> + [[ -d <http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/ws/ovirt-system-test…> ]] + mv <http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/ws/ovirt-system-test…> <http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/584/artifact/exporte…> 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 <<EOC _______________________________________________________________________ ####################################################################### # # # 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" mock_root="${mock_conf_file##*/}" mock_root="${mock_root%.*}" my_mock="/usr/bin/mock" my_mock+=" --configdir=${mock_conf_file%/*}" my_mock+=" --root=${mock_root}" my_mock+=" --resultdir=$WORKSPACE" #TODO: investigate why mock --clean fails to umount certain dirs sometimes, #so we can use it instead of manually doing all this. echo "Killing all mock orphan processes, if any." $my_mock \ --orphanskill \ || { echo "ERROR: Failed to kill orphans on $chroot." failed=true } mock_root="$(\ grep \ -Po "(?<=config_opts\['root'\] = ')[^']*" \ "$mock_conf_file" \ )" || : [[ "$mock_root" ]] || continue mounts=($(mount | awk '{print $3}' | grep "$mock_root")) || : if [[ "$mounts" ]]; then echo "Found mounted dirs inside the chroot $chroot. Trying to umount." fi for mount in "${mounts[@]}"; do sudo umount --lazy "$mount" \ || { echo "ERROR: Failed to umount $mount." failed=true } done done # Clean any leftover chroot from other jobs for mock_root in /var/lib/mock/*; do this_chroot_failed=false mounts=($(mount | awk '{print $3}' | grep "$mock_root")) || : if [[ "$mounts" ]]; then echo "Found mounted dirs inside the chroot $mock_root." \ "Trying to umount." fi for mount in "${mounts[@]}"; do sudo umount --lazy "$mount" \ || { echo "ERROR: Failed to umount $mount." failed=true this_chroot_failed=true } done if ! $this_chroot_failed; then sudo rm -rf "$mock_root" fi done if $failed; then echo "Aborting." exit 1 fi # remove mock caches that are older then 2 days: find /var/cache/mock/ -mindepth 1 -maxdepth 1 -type d -mtime +2 -print0 | \ xargs -0 -tr sudo rm -rf # We make no effort to leave around caches that may still be in use because # packages installed in them may go out of date, so may as well recreate them # restore the permissions in the working dir, as sometimes it leaves files # owned by root and then the 'cleanup workspace' from jenkins job fails to # clean and breaks the jobs sudo chown -R "$USER" "$WORKSPACE" # Drop all left over libvirt domains for UUID in $(virsh list --all --uuid); do virsh destroy $UUID || : sleep 2 virsh undefine --remove-all-storage --storage vda --snapshots-metadata $UUID || : done [ovirt_4.0_he-system-tests] $ /bin/bash -xe /tmp/hudson5288074319744005272.sh + echo shell-scripts/mock_cleanup.sh shell-scripts/mock_cleanup.sh + shopt -s nullglob + WORKSPACE=<http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/ws/> + 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 <http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/ws/ovirt-system-test…> ]] + 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=<http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/ws/ovirt-system-tests'> + my_mock+=' --root=mocker-epel-7-x86_64.el7' + my_mock+=' --resultdir=<http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/ws/'> + echo 'Killing all mock orphan processes, if any.' Killing all mock orphan processes, if any. + /usr/bin/mock --configdir=<http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/ws/ovirt-system-tests> --root=mocker-epel-7-x86_64.el7 --resultdir=<http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/ws/> --orphanskill WARNING: Could not find required logging config file: <http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/ws/ovirt-system-test….> Using default... INFO: mock.py version 1.2.21 starting (python version = 3.4.3)... Start: init plugins INFO: selinux enabled Finish: init plugins Start: run Finish: run ++ grep -Po '(?<=config_opts\['\''root'\''\] = '\'')[^'\'']*' <http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/ws/ovirt-system-test…> + mock_root=epel-7-x86_64-ed452d1ea0f6dadf50c66d3b3f6b3a6e + [[ -n epel-7-x86_64-ed452d1ea0f6dadf50c66d3b3f6b3a6e ]] + mounts=($(mount | awk '{print $3}' | grep "$mock_root")) ++ mount ++ awk '{print $3}' ++ grep epel-7-x86_64-ed452d1ea0f6dadf50c66d3b3f6b3a6e + : + [[ -n '' ]] + false + find /var/cache/mock/ -mindepth 1 -maxdepth 1 -type d -mtime +2 -print0 + xargs -0 -tr sudo rm -rf + sudo chown -R jenkins <http://jenkins.ovirt.org/job/ovirt_4.0_he-system-tests/ws/> ++ virsh list --all --uuid POST BUILD TASK : SUCCESS END OF POST BUILD TASK : 1 Recording test results ERROR: Step ‘Publish JUnit test result report’ failed: No test report files were found. Configuration error? Archiving artifacts

1 2

[JIRA] (OVIRT-916) false CI-1 : failing to clone git://gerrit.ovirt.org
by Barak Korren (oVirt JIRA) 07 Dec '16

07 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-916?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-916: ------------------------------- Resolution: Duplicate Status: Done (was: To Do) Patch already pending to fix this. Also manually cleaned the slave for now. > false CI-1 : failing to clone git://gerrit.ovirt.org > ---------------------------------------------------- > > Key: OVIRT-916 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-916 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: danken > Assignee: infra > > The patch https://gerrit.ovirt.org/#/c/55778/ is now pending merge due > to irrelevant failure of > http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch-el7-x86_64/144… > [EnvInject] - Loading node environment variables. > Building remotely on vm0120.workers-phx.ovirt.org (fc24 phx nested) in > workspace /home/jenkins/workspace/ovirt-engine_master_check-patch-el7-x86_64 > > git rev-parse --is-inside-work-tree # timeout=10 > Fetching changes from the remote Git repository > > git config remote.origin.url > git://gerrit.ovirt.org/ovirt-engine.git # timeout=10 > Cleaning workspace > > git rev-parse --verify HEAD # timeout=10 > Resetting working tree > > git reset --hard # timeout=10 > > git clean -fdx # timeout=10 > ERROR: Error fetching remote repo 'origin' > hudson.plugins.git.GitException: Failed to fetch from > git://gerrit.ovirt.org/ovirt-engine.git > at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766) > at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022) > at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053) > at org.jenkinsci.plugins.multiplescms.MultiSCM.checkout(MultiSCM.java:129) > at hudson.scm.SCM.checkout(SCM.java:485) > at hudson.model.AbstractProject.checkout(AbstractProject.java:1269) > at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607) > at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) > at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529) > at hudson.model.Run.execute(Run.java:1738) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) > at hudson.model.ResourceController.execute(ResourceController.java:98) > at hudson.model.Executor.run(Executor.java:410) > Caused by: hudson.plugins.git.GitException: Command "git clean -fdx" > returned status code 1: -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-916) false CI-1 : failing to clone git://gerrit.ovirt.org
by danken (oVirt JIRA) 07 Dec '16

07 Dec '16

danken created OVIRT-916: ---------------------------- Summary: false CI-1 : failing to clone git://gerrit.ovirt.org Key: OVIRT-916 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-916 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: danken Assignee: infra The patch https://gerrit.ovirt.org/#/c/55778/ is now pending merge due to irrelevant failure of http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch-el7-x86_64/144… [EnvInject] - Loading node environment variables. Building remotely on vm0120.workers-phx.ovirt.org (fc24 phx nested) in workspace /home/jenkins/workspace/ovirt-engine_master_check-patch-el7-x86_64 > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url git://gerrit.ovirt.org/ovirt-engine.git # timeout=10 Cleaning workspace > git rev-parse --verify HEAD # timeout=10 Resetting working tree > git reset --hard # timeout=10 > git clean -fdx # timeout=10 ERROR: Error fetching remote repo 'origin' hudson.plugins.git.GitException: Failed to fetch from git://gerrit.ovirt.org/ovirt-engine.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053) at org.jenkinsci.plugins.multiplescms.MultiSCM.checkout(MultiSCM.java:129) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1269) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529) at hudson.model.Run.execute(Run.java:1738) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:410) Caused by: hudson.plugins.git.GitException: Command "git clean -fdx" returned status code 1: -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3993 - SUCCESS!
by jenkins＠jenkins.phx.ovirt.org 07 Dec '16

07 Dec '16

------=_Part_33_982867427.1481118689786 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3993/, Build Number: 3993, Build Status: SUCCESS ------=_Part_33_982867427.1481118689786--

1 0

[JIRA] (OVIRT-915) permission to run rpm-generating job
by Shlomo Ben David (oVirt JIRA) 07 Dec '16

07 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-915?page=com.atlassian.jira.p… ] Shlomo Ben David reassigned OVIRT-915: -------------------------------------- Assignee: Shlomo Ben David (was: infra) > permission to run rpm-generating job > ------------------------------------ > > Key: OVIRT-915 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-915 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: danken > Assignee: Shlomo Ben David > > Hi, > Would you grant myakove and mburman (CCed) the permission to log into > jenkins.ovirt.org and trigger jobs such as > http://jenkins.ovirt.org/job/ovirt-engine_4.0_build-artifacts-el7-x86_64-ma… > Regards, > Dan. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-915) permission to run rpm-generating job
by Shlomo Ben David (oVirt JIRA) 07 Dec '16

07 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-915?page=com.atlassian.jira.p… ] Shlomo Ben David commented on OVIRT-915: ---------------------------------------- Hi, I added your username to the 'dev' role in Jenkins. Best Regards, Shlomi Ben-David | DevOps Engineer | Red Hat ISRAEL RHCSA | RHCE IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci) OPEN SOURCE - 1 4 011 && 011 4 1 On Wed, Dec 7, 2016 at 3:17 PM, Meni Yakove (oVirt JIRA) < > permission to run rpm-generating job > ------------------------------------ > > Key: OVIRT-915 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-915 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: danken > Assignee: infra > > Hi, > Would you grant myakove and mburman (CCed) the permission to log into > jenkins.ovirt.org and trigger jobs such as > http://jenkins.ovirt.org/job/ovirt-engine_4.0_build-artifacts-el7-x86_64-ma… > Regards, > Dan. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-915) permission to run rpm-generating job
by Meni Yakove (oVirt JIRA) 07 Dec '16

07 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-915?page=com.atlassian.jira.p… ] Meni Yakove commented on OVIRT-915: ----------------------------------- Done > permission to run rpm-generating job > ------------------------------------ > > Key: OVIRT-915 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-915 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: danken > Assignee: infra > > Hi, > Would you grant myakove and mburman (CCed) the permission to log into > jenkins.ovirt.org and trigger jobs such as > http://jenkins.ovirt.org/job/ovirt-engine_4.0_build-artifacts-el7-x86_64-ma… > Regards, > Dan. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-915) permission to run rpm-generating job
by eyal edri [Administrator] (oVirt JIRA) 07 Dec '16

07 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-915?page=com.atlassian.jira.p… ] eyal edri [Administrator] commented on OVIRT-915: ------------------------------------------------- Please sign-up for the jenkins first and reply here, so we can give you 'dev' role permissions. On Wed, Dec 7, 2016 at 1:54 PM, danken (oVirt JIRA) < -- Eyal Edri Associate Manager RHV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ) > permission to run rpm-generating job > ------------------------------------ > > Key: OVIRT-915 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-915 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: danken > Assignee: infra > > Hi, > Would you grant myakove and mburman (CCed) the permission to log into > jenkins.ovirt.org and trigger jobs such as > http://jenkins.ovirt.org/job/ovirt-engine_4.0_build-artifacts-el7-x86_64-ma… > Regards, > Dan. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-915) permission to run rpm-generating job
by danken (oVirt JIRA) 07 Dec '16

07 Dec '16

danken created OVIRT-915: ---------------------------- Summary: permission to run rpm-generating job Key: OVIRT-915 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-915 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: danken Assignee: infra Hi, Would you grant myakove and mburman (CCed) the permission to log into jenkins.ovirt.org and trigger jobs such as http://jenkins.ovirt.org/job/ovirt-engine_4.0_build-artifacts-el7-x86_64-ma… Regards, Dan. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

2 1

[oVirt Jenkins] test-repo_ovirt_experimental_4.0 - Build #3410 - FAILURE!
by jenkins＠jenkins.phx.ovirt.org 07 Dec '16

07 Dec '16

------=_Part_13_1226181087.1481080158832 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4.0/3410/, Build Number: 3410, Build Status: FAILURE ------=_Part_13_1226181087.1481080158832--

1 7

[JIRA] (OVIRT-914) Better arch support for mock_runner.sh
by Barak Korren (oVirt JIRA) 07 Dec '16

07 Dec '16

Barak Korren created OVIRT-914: ---------------------------------- Summary: Better arch support for mock_runner.sh Key: OVIRT-914 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-914 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Jenkins Reporter: Barak Korren Assignee: infra We managed to us "{{mock_runner.sh}}" in multi-arch so far because it was flexible enough to allow us to select the chroot file. The issue is that mock_runner does not actually *know* the arch we are running on so we can`t:: * do different mounts per-arch * install different packages per-arch * have different {{check_*}} scripts per-arch -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-914) Better arch support for mock_runner.sh
by Barak Korren (oVirt JIRA) 07 Dec '16

07 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-914?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-914: ------------------------------- Epic Link: OVIRT-400 > Better arch support for mock_runner.sh > -------------------------------------- > > Key: OVIRT-914 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-914 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > > We managed to us "{{mock_runner.sh}}" in multi-arch so far because it was flexible enough to allow us to select the chroot file. > The issue is that mock_runner does not actually *know* the arch we are running on so we can`t:: > * do different mounts per-arch > * install different packages per-arch > * have different {{check_*}} scripts per-arch -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-913) Speed up mock with the `nosync` package
by Barak Korren (oVirt JIRA) 07 Dec '16

07 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-913?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-913: ------------------------------- Epic Link: OVIRT-400 > Speed up mock with the `nosync` package > --------------------------------------- > > Key: OVIRT-913 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-913 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > Labels: mock, mock_runner.sh, standard-ci > > The {{nosync}} package can make mock faster by making it ignore all {{sync(2)}} calls. > {{mock_runner.sh}} actually already enables this setting in the chroot configuration files, but it cannot work without the package. > We need to check if this actually makes mock faster, and if so, add it to the slaves. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-913) Speed up mock with the `nosync` package
by Barak Korren (oVirt JIRA) 07 Dec '16

07 Dec '16

Barak Korren created OVIRT-913: ---------------------------------- Summary: Speed up mock with the `nosync` package Key: OVIRT-913 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-913 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Jenkins Reporter: Barak Korren Assignee: infra The {{nosync}} package can make mock faster by making it ignore all {{sync(2)}} calls. {{mock_runner.sh}} actually already enables this setting in the chroot configuration files, but it cannot work without the package. We need to check if this actually makes mock faster, and if so, add it to the slaves. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-912) Brand oVirt Gerrit
by Barak Korren (oVirt JIRA) 07 Dec '16

07 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-912?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-912: ------------------------------- Component/s: Gerrit/git > Brand oVirt Gerrit > ------------------ > > Key: OVIRT-912 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-912 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Gerrit/git > Reporter: Barak Korren > Assignee: infra > Labels: branding, gerrit, look-and-feel > > It is not branded - we need to brand it so it feels more like what it is - oVirt's development home. > We need to find ways to make people proud to belong to a project big enough to have its own code hosting, instead of constantly looking to GitHub. (Maybe this should be an epic) > Look at OpenStack's Gerrit for example: https://review.openstack.org/#/q/status:open -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-912) Brand oVirt Gerrit
by Barak Korren (oVirt JIRA) 07 Dec '16

07 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-912?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-912: ------------------------------- Labels: branding gerrit look-and-feel (was: ) > Brand oVirt Gerrit > ------------------ > > Key: OVIRT-912 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-912 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Gerrit/git > Reporter: Barak Korren > Assignee: infra > Labels: branding, gerrit, look-and-feel > > It is not branded - we need to brand it so it feels more like what it is - oVirt's development home. > We need to find ways to make people proud to belong to a project big enough to have its own code hosting, instead of constantly looking to GitHub. (Maybe this should be an epic) > Look at OpenStack's Gerrit for example: https://review.openstack.org/#/q/status:open -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-912) Brand oVirt Gerrit
by Barak Korren (oVirt JIRA) 07 Dec '16

07 Dec '16

Barak Korren created OVIRT-912: ---------------------------------- Summary: Brand oVirt Gerrit Key: OVIRT-912 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-912 Project: oVirt - virtualization made easy Issue Type: Improvement Reporter: Barak Korren Assignee: infra It is not branded - we need to brand it so it feels more like what it is - oVirt's development home. We need to find ways to make people proud to belong to a project big enough to have its own code hosting, instead of constantly looking to GitHub. (Maybe this should be an epic) Look at OpenStack's Gerrit for example: https://review.openstack.org/#/q/status:open -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-912) Brand oVirt Gerrit
by Barak Korren (oVirt JIRA) 07 Dec '16

07 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-912?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-912: ------------------------------- Epic Link: OVIRT-403 > Brand oVirt Gerrit > ------------------ > > Key: OVIRT-912 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-912 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Barak Korren > Assignee: infra > > It is not branded - we need to brand it so it feels more like what it is - oVirt's development home. > We need to find ways to make people proud to belong to a project big enough to have its own code hosting, instead of constantly looking to GitHub. (Maybe this should be an epic) > Look at OpenStack's Gerrit for example: https://review.openstack.org/#/q/status:open -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3983 - SUCCESS!
by jenkins＠jenkins.phx.ovirt.org 07 Dec '16

07 Dec '16

------=_Part_23_599581856.1481097419478 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3983/, Build Number: 3983, Build Status: SUCCESS ------=_Part_23_599581856.1481097419478--

1 0

oVirt infra daily report - unstable production jobs - 160
by jenkins＠jenkins.phx.ovirt.org 07 Dec '16

07 Dec '16

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/160//artifact/exported-a… Cheers, Jenkins

1 0

[JIRA] (OVIRT-909) Several git errors in several jobs
by Barak Korren (oVirt JIRA) 06 Dec '16

06 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-909?page=com.atlassian.jira.p… ] Barak Korren reassigned OVIRT-909: ---------------------------------- Assignee: Barak Korren (was: infra) > Several git errors in several jobs > ---------------------------------- > > Key: OVIRT-909 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-909 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Jenkins > Reporter: Fabian Deutsch > Assignee: Barak Korren > Priority: Highest > > The following jobs all had the same git issue, first cloning then cleaning: > * * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > This happened several times in the last weeks. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-909) Several git errors in several jobs
by Barak Korren (oVirt JIRA) 06 Dec '16

06 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-909?page=com.atlassian.jira.p… ] Barak Korren commented on OVIRT-909: ------------------------------------ [~fdeutsch] sudo rm will just mean you need to re-clone everything from Gerrit every time the job runs, its a waste of time... I will try to send a patch for this soon > Several git errors in several jobs > ---------------------------------- > > Key: OVIRT-909 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-909 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Jenkins > Reporter: Fabian Deutsch > Assignee: infra > Priority: Highest > > The following jobs all had the same git issue, first cloning then cleaning: > * * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > This happened several times in the last weeks. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-909) Several git errors in several jobs
by eyal edri [Administrator] (oVirt JIRA) 06 Dec '16

06 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-909?page=com.atlassian.jira.p… ] eyal edri [Administrator] commented on OVIRT-909: ------------------------------------------------- [~bkorren(a)redhat.com] can you help with the patch to fix mock cleanup? I'm not sure [~ederevea] is familiar enough with standard ci and we need it fixed soon so node jobs can run > Several git errors in several jobs > ---------------------------------- > > Key: OVIRT-909 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-909 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Jenkins > Reporter: Fabian Deutsch > Assignee: infra > Priority: Highest > > The following jobs all had the same git issue, first cloning then cleaning: > * * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > This happened several times in the last weeks. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-909) Several git errors in several jobs
by Fabian Deutsch (oVirt JIRA) 06 Dec '16

06 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-909?page=com.atlassian.jira.p… ] Fabian Deutsch commented on OVIRT-909: -------------------------------------- Could be the case, because libvirt is involved, which might also touch this directory, which could be setting different users. What about sudo rm'ing the workspace? I'm open to any fix for this issue. > Several git errors in several jobs > ---------------------------------- > > Key: OVIRT-909 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-909 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Jenkins > Reporter: Fabian Deutsch > Assignee: infra > Priority: Highest > > The following jobs all had the same git issue, first cloning then cleaning: > * * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > This happened several times in the last weeks. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-911) Move repo closure to run in STD-CI
by Gil Shinar (oVirt JIRA) 06 Dec '16

06 Dec '16

Gil Shinar created OVIRT-911: -------------------------------- Summary: Move repo closure to run in STD-CI Key: OVIRT-911 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-911 Project: oVirt - virtualization made easy Issue Type: Task Reporter: Gil Shinar Assignee: infra Repo closure jobs are currently running on VMs. We would like to change these jobs to run inside mocks as STD-CI. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-910) mock_runner.sh seems to run slower on newer slaves
by Barak Korren (oVirt JIRA) 06 Dec '16

06 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-910?page=com.atlassian.jira.p… ] Barak Korren commented on OVIRT-910: ------------------------------------ the problem with logs is that you need to get then "hot" be cause they may disappear fast... Older slave log (fc24-vm15.phx.ovirt.org) http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/5915/ {code} ... 12:01:51 Start: unpacking root cache 12:02:06 Finish: unpacking root cache ... 12:02:07 Init took 17 seconds {code} Newer slave log (vm0125.workers-phx.ovirt.org) http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/5916/ {code} ... 12:04:19 Start: unpacking root cache 12:05:15 Finish: unpacking root cache ... 12:05:16 Init took 57 seconds {code} Then again, on (newer) vm0130.workers-phx.ovirt.org: http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/5916/ {code} ... 12:02:45 Start: unpacking root cache 12:03:09 Finish: unpacking root cache ... 12:03:09 Init took 24 seconds {code} So not a 100% consistent result, still, we should find out how to get those 40 seconds back... BTW I was sure the local disk was mounted on older slaves with noatime, looks like that is not the case, maybe we should fix that... > mock_runner.sh seems to run slower on newer slaves > -------------------------------------------------- > > Key: OVIRT-910 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-910 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > > After implementing speedup improvements for mock_runner.sh (Specifically enabling it to deploy the chroot by extracting a tarball as opposed to installing it with yum every time), I started monitoring run times for vdsm check_patch jobs. > I've noticed that jobs that are running on the old slaves (fc24-vm*) seem to initialize mock faster then ones running on new slaves (vm*) - 17seconds vs 57 seconds respectively. > I suspect this may be because the older slaves have a different FS mounted on /var/cache/mock -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-904) False CI-1 due to unreachable copr-be.cloud.fedoraproject.org
by Greg Sheremeta (oVirt JIRA) 06 Dec '16

06 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-904?page=com.atlassian.jira.p… ] Greg Sheremeta commented on OVIRT-904: -------------------------------------- I maintain patternfly on copr. No one else uses it, so we can move it anywhere that makes sense. > False CI-1 due to unreachable copr-be.cloud.fedoraproject.org > ------------------------------------------------------------- > > Key: OVIRT-904 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-904 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: danken > Assignee: infra > > Many patches on > https://gerrit.ovirt.org/#/q/topic:passthroughMigration fail CI due to > failure: repodata/repomd.xml from patternfly: [Errno 256] No more > mirrors to try. > http://copr-be.cloud.fedoraproject.org/results/patternfly/patternfly1/epel-…: > [Errno 14] curl#7 - "Failed connect to > copr-be.cloud.fedoraproject.org:80; No route to host" > http://copr-be.cloud.fedoraproject.org/results/patternfly/patternfly1/epel-… -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-910) mock_runner.sh seems to run slower on newer slaves
by Evgheni Dereveanchin (oVirt JIRA) 06 Dec '16

06 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-910?page=com.atlassian.jira.p… ] Evgheni Dereveanchin commented on OVIRT-910: -------------------------------------------- [~bkorren(a)redhat.com] some logs would be helpful :) Older slaves with local disk hook use ext4 on the secondary disk while newer ones write to rootfs which is XFS. I can try launching a dozen ext4 VMs so that we can compare performance. > mock_runner.sh seems to run slower on newer slaves > -------------------------------------------------- > > Key: OVIRT-910 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-910 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > > After implementing speedup improvements for mock_runner.sh (Specifically enabling it to deploy the chroot by extracting a tarball as opposed to installing it with yum every time), I started monitoring run times for vdsm check_patch jobs. > I've noticed that jobs that are running on the old slaves (fc24-vm*) seem to initialize mock faster then ones running on new slaves (vm*) - 17seconds vs 57 seconds respectively. > I suspect this may be because the older slaves have a different FS mounted on /var/cache/mock -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-910) mock_runner.sh seems to run slower on newer slaves
by Barak Korren (oVirt JIRA) 06 Dec '16

06 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-910?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-910: ------------------------------- Description: After implementing speedup improvements for mock_runner.sh (Specifically enabling it to deploy the chroot by extracting a tarball as opposed to installing it with yum every time), I started monitoring run times for vdsm check_patch jobs. I've noticed that jobs that are running on the old slaves (fc24-vm*) seem to initialize mock faster then ones running on new slaves (vm*) - 17seconds vs 57 seconds respectively. I suspect this may be because the older slaves have a different FS mounted on /var/cache/mock was: After implementing speedup improvements for mock_runner.sh (Specifically enabling it to deploy the chroot by extracting a tarball as opposed to installing it with yum every time), I started monitoring run times for vdsm check_patch jobs. I've noticed that jobs that are running on the old slaves (fc24-vm*) seem to initialize mock faster then ones running on new slaves (vm*) - 17seconds vs 57 seconds respectively. I suspect this may be because the older slaves have a different FS mounted on /var/lib/mock > mock_runner.sh seems to run slower on newer slaves > -------------------------------------------------- > > Key: OVIRT-910 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-910 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > > After implementing speedup improvements for mock_runner.sh (Specifically enabling it to deploy the chroot by extracting a tarball as opposed to installing it with yum every time), I started monitoring run times for vdsm check_patch jobs. > I've noticed that jobs that are running on the old slaves (fc24-vm*) seem to initialize mock faster then ones running on new slaves (vm*) - 17seconds vs 57 seconds respectively. > I suspect this may be because the older slaves have a different FS mounted on /var/cache/mock -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-910) mock_runner.sh seems to run slower on newer slaves
by Barak Korren (oVirt JIRA) 06 Dec '16

06 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-910?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-910: ------------------------------- Epic Link: OVIRT-400 > mock_runner.sh seems to run slower on newer slaves > -------------------------------------------------- > > Key: OVIRT-910 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-910 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > > After implementing speedup improvements for mock_runner.sh (Specifically enabling it to deploy the chroot by extracting a tarball as opposed to installing it with yum every time), I started monitoring run times for vdsm check_patch jobs. > I've noticed that jobs that are running on the old slaves (fc24-vm*) seem to initialize mock faster then ones running on new slaves (vm*) - 17seconds vs 57 seconds respectively. > I suspect this may be because the older slaves have a different FS mounted on /var/lib/mock -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-910) mock_runner.sh seems to run slower on newer slaves
by Barak Korren (oVirt JIRA) 06 Dec '16

06 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-910?page=com.atlassian.jira.p… ] Barak Korren commented on OVIRT-910: ------------------------------------ [~ederevea], [~amarchuk] any idea what we can do to improve this? > mock_runner.sh seems to run slower on newer slaves > -------------------------------------------------- > > Key: OVIRT-910 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-910 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > > After implementing speedup improvements for mock_runner.sh (Specifically enabling it to deploy the chroot by extracting a tarball as opposed to installing it with yum every time), I started monitoring run times for vdsm check_patch jobs. > I've noticed that jobs that are running on the old slaves (fc24-vm*) seem to initialize mock faster then ones running on new slaves (vm*) - 17seconds vs 57 seconds respectively. > I suspect this may be because the older slaves have a different FS mounted on /var/lib/mock -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-910) mock_runner.sh seems to run slower on newer slaves
by Barak Korren (oVirt JIRA) 06 Dec '16

06 Dec '16

Barak Korren created OVIRT-910: ---------------------------------- Summary: mock_runner.sh seems to run slower on newer slaves Key: OVIRT-910 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-910 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Jenkins Reporter: Barak Korren Assignee: infra After implementing speedup improvements for mock_runner.sh (Specifically enabling it to deploy the chroot by extracting a tarball as opposed to installing it with yum every time), I started monitoring run times for vdsm check_patch jobs. I've noticed that jobs that are running on the old slaves (fc24-vm*) seem to initialize mock faster then ones running on new slaves (vm*) - 17seconds vs 57 seconds respectively. I suspect this may be because the older slaves have a different FS mounted on /var/lib/mock -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-909) Several git errors in several jobs
by Barak Korren (oVirt JIRA) 06 Dec '16

06 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-909?page=com.atlassian.jira.p… ] Barak Korren commented on OVIRT-909: ------------------------------------ Hmm... I can make an educated guess that what we're seeing here is that some files in the local git clone belong to the root user as opposed to the jenkins user. This could happen if something from inside mock is running any git commands that write to the repo... I guess what we could do is make mock_cleanup.sh ensure that no file are left in $WORKSPACE that do not belong the 'jenkins' > Several git errors in several jobs > ---------------------------------- > > Key: OVIRT-909 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-909 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Jenkins > Reporter: Fabian Deutsch > Assignee: infra > Priority: Highest > > The following jobs all had the same git issue, first cloning then cleaning: > * * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > This happened several times in the last weeks. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0