January 2018 - Infra - oVirt List Archives

Mailing-Lists upgrade
by Marc Dequènes (Duck) 10 May '18

10 May '18

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IfGqXrbgT9wNNdIsvS8kI8WdhEQHlgkiq Content-Type: multipart/mixed; boundary="AUFHCWPQQknM84fF2kF4uGjIv4blC9bMv"; protected-headers="v1" From: =?UTF-8?B?TWFyYyBEZXF1w6huZXMgKER1Y2sp?= <duck(a)redhat.com> To: oVirt Infra <infra(a)ovirt.org>, users <users(a)ovirt.org>, devel <devel(a)ovirt.org> Message-ID: <c5c71fce-0290-e97a-ddd0-eab0e6fccea4(a)redhat.com> Subject: Mailing-Lists upgrade --AUFHCWPQQknM84fF2kF4uGjIv4blC9bMv Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Quack, On behalf of the oVirt infra team, I'd like to announce the current Mailing-Lists system is going to be upgraded to a brand new Mailman 3 installation on Monday during the slot 11:00-12:00 JST. It should not take a full hour to migrate as we already made incremental synchronization with the current system but better keep some margin. The system will then take over delivery of the mails but might be a bit slow at first as it needs to reindex all the archived mails (which might take a few hours). To manage your subscriptions and delivery settings you can do this easily on the much nicer web interface (https://lists.ovirt.org) There is a notion of account so you don't need to login separately for each ML.= You can Sign In using Fedora, GitHub or Google or create a local account if you prefer. Please keep in mind signing in with a different method would create separate accounts (which cannot be merged at the moment). But you can easily link your account to other authentication methods in your settings (click on you name in the up-right corner -> Account -> Account Connections). As for the original mail archives, because the previous system did not have stable URLs, we cannot create mappings to the new pages. We decided to keep the old archives around on the same URL (/pipermail), so the Internet links would still work fine. Hope you'd be happy with the new system. \_o< --AUFHCWPQQknM84fF2kF4uGjIv4blC9bMv-- --IfGqXrbgT9wNNdIsvS8kI8WdhEQHlgkiq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEcpcqg+UmRT3yiF+BVen596wcRD8FAlmwx0MACgkQVen596wc RD9LTQ/+LtUncsq9K8D/LX8wqUTd6VyPwAD5UnAk5c3H/2tmyVA0u7FIfhEyPsXs Z//LE9FEneTDqDVRi1Dw9I54K0ZwxPBemi71dXfwgBI7Ay0ezkbLWrA168Mt9spE tHAODEuxPt2to2aqaS4ujogrkp/gvEP8ILoxPEqoTPCJ/eDTPAu/I1a2JzjMPK3n 2BBS6D8z0TLAf7w1n72TsgX2QzJW57ig/0HELyjvat2/K8V3HSrkwiKlsdULQDWe zB+aMde7r6UoyVKHqlu4asTl2tU/lGZ+e31Hd9Bnx1/oZOJdzslGOhEo9Qoz6763 AHWU9LKiK4NtxYHj2UQTWhndr8PiTtTmR73eIDmkb0cuRXxzjl9VQbwYJ0Kbrmfp attTqpc2CnEojTNXUUNSmNxotZoYXZiX8ZvjPfSgRVr15TUYujzlOfG+lUynbQMV 9rQ9/m58wgwYUymMpOIsRGaIcAKzjm+WpuuVnO+bS2AfmcBkGMQRoIhfV+3SkS8q kT9cDXgcDZOzVFcnZZB4EjbycMcPgZDcoHxU88VdYH+jFJYvvb21esgswVF/wJ2Z uEI/chp4+ADaQhl8ehZNWMSZq125v6SeirPhBNgLG7zFVZI1S9Tm/6qFmH+ajQY7 nCk1X9HZlB1ubex1X+HibRz9QKOilkMgkADyJ4yMDckwYj93sx0= =l6uN -----END PGP SIGNATURE----- --IfGqXrbgT9wNNdIsvS8kI8WdhEQHlgkiq--

5 11

[oVirt Jenkins] ovirt-appliance_ovirt-4.2_build-artifacts-el7-x86_64 - Build # 25 - Failure!
by jenkins＠jenkins.phx.ovirt.org 06 Feb '18

06 Feb '18

------=_Part_430_1552023397.1517315123106 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-appliance_ovirt-4.2_build-artifacts-el7-… Build: http://jenkins.ovirt.org/job/ovirt-appliance_ovirt-4.2_build-artifacts-el7-… Build Number: 25 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #25 [Daniel Belenky] Add ipinto(a)redhat.com to whitelist [Sandro Bonazzola] vcredist-x86: move to 4.2 and latest fedora [Sandro Bonazzola] pywin32-py2.7: move to 4.2 and latest fedora [Sandro Bonazzola] python-windows: move to 4.2 and latest fedora [Sandro Bonazzola] py2exe-py2.7: move to 4.2 and latest fedora [Sandro Bonazzola] nsis-simple-service-plugin:: move to 4.2 and latest fedora [Daniel Belenky] Bound vdsm check-merged to el7 hosts only [Barak Korren] Make standard-enqueue support non-ovirt queues [Barak Korren] Allow customizing CQ mail addresses [Barak Korren] Enable customizing the server we deploy tested to [Barak Korren] Make pipeline-loader support upstream sources [Barak Korren] Made clone url for 'jenkins' customizable [Sandro Bonazzola] copy-create-job: drop EOLed Fedoras [Dafna Ron] otopi - dropping fc24 [Dafna Ron] ovirt-hosted-engine-setup - dropping fc24 [Daniel Belenky] Mock runner to search full script path [Sandro Bonazzola] otopi: 4.2 and latest fedora [Sandro Bonazzola] ovirt-hosted-engine-setup: 4.2 and new Fedoras [Sandro Bonazzola] ovirt-live: drop project [Daniel Belenky] Introduce Gerrit pipelines [Martin Perina] ovirt-engine-extensions: Add 4.2 jobs for all engine extensions [Yuval Turgeman] Resolve network issues in kickstart ----------------- Failed Tests: ----------------- No tests ran. ------=_Part_430_1552023397.1517315123106--

1 1

[oVirt Jenkins] ovirt-system-tests_hc-basic-suite-4.1 - Build # 166 - Failure!
by jenkins＠jenkins.phx.ovirt.org 05 Feb '18

05 Feb '18

------=_Part_381_1544163873.1517107231092 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-4.1/ Build: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-4.1/166/ Build Number: 166 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #166 [Dan Kenigsberg] networking: vm_operations: use a vm with a vnic ----------------- Failed Tests: ----------------- No tests ran. ------=_Part_381_1544163873.1517107231092--

3 12

[oVirt Jenkins] ovirt-system-tests_hc-basic-suite-master - Build # 159 - Failure!
by jenkins＠jenkins.phx.ovirt.org 05 Feb '18

05 Feb '18

------=_Part_113_1228656558.1516074596162 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-master/ Build: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-master/159/ Build Number: 159 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #159 [Gal Ben Haim] 4.2: Adding 4.2 pre repo ----------------- Failed Tests: ----------------- 1 tests failed. FAILED: 002_bootstrap.add_hosts Error Message: Host lago-hc-basic-suite-master-host1 failed to install -------------------- >> begin captured logging << -------------------- ovirtlago.testlib: ERROR: * Unhandled exception in <function _host_is_up at 0x3d80668> Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 219, in assert_equals_within res = func() File "/home/jenkins/workspace/ovirt-system-tests_hc-basic-suite-master/ovirt-system-tests/hc-basic-suite-master/test-scenarios/002_bootstrap.py", line 151, in _host_is_up raise RuntimeError('Host %s failed to install' % host.name()) RuntimeError: Host lago-hc-basic-suite-master-host1 failed to install --------------------- >> end captured logging << --------------------- Stack Trace: File "/usr/lib64/python2.7/unittest/case.py", line 369, in run testMethod() File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 129, in wrapped_test test() File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 59, in wrapper return func(get_test_prefix(), *args, **kwargs) File "/home/jenkins/workspace/ovirt-system-tests_hc-basic-suite-master/ovirt-system-tests/hc-basic-suite-master/test-scenarios/002_bootstrap.py", line 164, in add_hosts testlib.assert_true_within(_host_is_up, timeout=15 * 60) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 263, in assert_true_within assert_equals_within(func, True, timeout, allowed_exceptions) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 219, in assert_equals_within res = func() File "/home/jenkins/workspace/ovirt-system-tests_hc-basic-suite-master/ovirt-system-tests/hc-basic-suite-master/test-scenarios/002_bootstrap.py", line 151, in _host_is_up raise RuntimeError('Host %s failed to install' % host.name()) 'Host lago-hc-basic-suite-master-host1 failed to install\n-------------------- >> begin captured logging << --------------------\novirtlago.testlib: ERROR: * Unhandled exception in <function _host_is_up at 0x3d80668>\nTraceback (most recent call last):\n File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 219, in assert_equals_within\n res = func()\n File "/home/jenkins/workspace/ovirt-system-tests_hc-basic-suite-master/ovirt-system-tests/hc-basic-suite-master/test-scenarios/002_bootstrap.py", line 151, in _host_is_up\n raise RuntimeError(\'Host %s failed to install\' % host.name())\nRuntimeError: Host lago-hc-basic-suite-master-host1 failed to install\n--------------------- >> end captured logging << ---------------------' ------=_Part_113_1228656558.1516074596162--

1 23

[oVirt Jenkins] ovirt-appliance_ovirt-4.1-snapshot_build-artifacts-el7-x86_64 - Build # 420 - Failure!
by jenkins＠jenkins.phx.ovirt.org 02 Feb '18

02 Feb '18

------=_Part_433_95654047.1517325891079 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-appliance_ovirt-4.1-snapshot_build-artif… Build: http://jenkins.ovirt.org/job/ovirt-appliance_ovirt-4.1-snapshot_build-artif… Build Number: 420 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #420 [Sandro Bonazzola] copy-create-job: drop EOLed Fedoras [Dafna Ron] otopi - dropping fc24 [Dafna Ron] ovirt-hosted-engine-setup - dropping fc24 [Daniel Belenky] Mock runner to search full script path [Sandro Bonazzola] otopi: 4.2 and latest fedora [Sandro Bonazzola] ovirt-hosted-engine-setup: 4.2 and new Fedoras [Sandro Bonazzola] ovirt-live: drop project [Daniel Belenky] Introduce Gerrit pipelines [Martin Perina] ovirt-engine-extensions: Add 4.2 jobs for all engine extensions [Dafna Ron] ovirt-release - dropping fc24 [Sandro Bonazzola] ovirt-hosted-engine-setup: re-add fc27 to 4.2 [Sandro Bonazzola] ovirt-release: re-align [Dafna Ron] ovirt-setup-lib - dropping fc24 [Sandro Bonazzola] ovirt-setup-lib: re-align [Dafna Ron] ovirt-iso-uploader - dropping fc24 [Sandro Bonazzola] ovirt-iso-uploader: re-align [Yuval Turgeman] automation: view install log in console ----------------- Failed Tests: ----------------- No tests ran. ------=_Part_433_95654047.1517325891079--

1 3

[oVirt Jenkins] ovirt-appliance_ovirt-4.2-snapshot_build-artifacts-el7-x86_64 - Build # 151 - Failure!
by jenkins＠jenkins.phx.ovirt.org 02 Feb '18

02 Feb '18

------=_Part_441_1359819724.1517368692698 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-appliance_ovirt-4.2-snapshot_build-artif… Build: http://jenkins.ovirt.org/job/ovirt-appliance_ovirt-4.2-snapshot_build-artif… Build Number: 151 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #151 [Sandro Bonazzola] copy-create-job: drop EOLed Fedoras [Dafna Ron] otopi - dropping fc24 [Dafna Ron] ovirt-hosted-engine-setup - dropping fc24 [Daniel Belenky] Mock runner to search full script path [Sandro Bonazzola] otopi: 4.2 and latest fedora [Sandro Bonazzola] ovirt-hosted-engine-setup: 4.2 and new Fedoras [Sandro Bonazzola] ovirt-live: drop project [Daniel Belenky] Introduce Gerrit pipelines [Martin Perina] ovirt-engine-extensions: Add 4.2 jobs for all engine extensions [Dafna Ron] ovirt-release - dropping fc24 [Sandro Bonazzola] ovirt-hosted-engine-setup: re-add fc27 to 4.2 [Sandro Bonazzola] ovirt-release: re-align [Dafna Ron] ovirt-setup-lib - dropping fc24 [Sandro Bonazzola] ovirt-setup-lib: re-align [Dafna Ron] ovirt-iso-uploader - dropping fc24 [Sandro Bonazzola] ovirt-iso-uploader: re-align [Dafna Ron] ovirt-guest-agent - dropping fc24 [Yuval Turgeman] Resolve network issues in kickstart ----------------- Failed Tests: ----------------- No tests ran. ------=_Part_441_1359819724.1517368692698--

1 1

[oVirt Jenkins] ovirt-appliance_master_build-artifacts-el7-x86_64 - Build # 691 - Failure!
by jenkins＠jenkins.phx.ovirt.org 01 Feb '18

01 Feb '18

------=_Part_445_1158474491.1517409089560 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-appliance_master_build-artifacts-el7-x86… Build: http://jenkins.ovirt.org/job/ovirt-appliance_master_build-artifacts-el7-x86… Build Number: 691 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #691 [Dafna Ron] ovirt-setup-lib - dropping fc24 [Sandro Bonazzola] ovirt-setup-lib: re-align [Dafna Ron] ovirt-iso-uploader - dropping fc24 [Sandro Bonazzola] ovirt-iso-uploader: re-align [Dafna Ron] ovirt-guest-agent - dropping fc24 [Dafna Ron] ovirt-host-deploy - dropping fc24 [Sandro Bonazzola] ovirt-host-deploy: re-align [Dafna Ron] ovirt-engine-wildfly - dropping fc24 [Sandro Bonazzola] ovirt-engine-wildfly: re-align [Evgheni Dereveanchin] Update mirror snapshot for FC27 to fix gdbm [Dafna Ron] ovirt-engine-wildfly-overlay - dropping fc24 [Yuval Turgeman] appliance-report: try to mount /var ----------------- Failed Tests: ----------------- No tests ran. ------=_Part_445_1158474491.1517409089560--

1 1

[JIRA] (OVIRT-1870) kubevirt_kubevirt_standard-check-pr jobs often get stuck
by Evgheni Dereveanchin (oVirt JIRA) 31 Jan '18

31 Jan '18

Evgheni Dereveanchin created OVIRT-1870: ------------------------------------------- Summary: kubevirt_kubevirt_standard-check-pr jobs often get stuck Key: OVIRT-1870 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1870 Project: oVirt - virtualization made easy Issue Type: Bug Reporter: Evgheni Dereveanchin Assignee: infra kubevirt_kubevirt_standard-check-pr jobs often get stuck waiting forever for a connection to get established: http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/376/console http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/377/console http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/378/console http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/380/console The following message keeps repeating all the time: 17:03:32 [check-patch.el7.x86_64] ++ awk '/virt-controller/ && /true/' 17:03:32 [check-patch.el7.x86_64] ++ kubectl get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers 17:03:32 [check-patch.el7.x86_64] ++ wc -l 17:03:32 [check-patch.el7.x86_64] ++ cluster/kubectl.sh get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers 17:03:44 [check-patch.el7.x86_64] Unable to connect to the server: dial tcp 192.168.121.111:6443: getsockopt: no route to host 17:03:44 [check-patch.el7.x86_64] + '[' 0 -lt 1 ']' 17:03:44 [check-patch.el7.x86_64] + echo 'Waiting for KubeVirt virt-controller container to become ready ...' 17:03:44 [check-patch.el7.x86_64] Waiting for KubeVirt virt-controller container to become ready ... 17:03:44 [check-patch.el7.x86_64] + kubectl get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers 17:03:44 [check-patch.el7.x86_64] + awk '/virt-controller/ && /true/' 17:03:44 [check-patch.el7.x86_64] + cluster/kubectl.sh get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers 17:03:44 [check-patch.el7.x86_64] + wc -l 17:03:56 [check-patch.el7.x86_64] Unable to connect to the server: dial tcp 192.168.121.111:6443: getsockopt: no route to host 17:03:56 [check-patch.el7.x86_64] 0 17:03:56 [check-patch.el7.x86_64] + sleep 10 Need to implement timeouts as this takes up bare metal systems for days and weeks until someone manually kills the job -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

Build failed in Jenkins: system-sync_mirrors-centos-updates-el7-x86_64 #1229
by jenkins＠jenkins.phx.ovirt.org 31 Jan '18

31 Jan '18

See <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-updates-el7-x86_64/…> Changes: [Dafna Ron] ovirt-host-deploy - dropping fc24 [Sandro Bonazzola] ovirt-host-deploy: re-align [Dafna Ron] ovirt-engine-wildfly - dropping fc24 [Sandro Bonazzola] ovirt-engine-wildfly: re-align [Evgheni Dereveanchin] Update mirror snapshot for FC27 to fix gdbm [Dafna Ron] ovirt-engine-wildfly-overlay - dropping fc24 [Sandro Bonazzola] ovirt-engine-wildfly-overlay: re-align [Gal Ben Haim] kubevirt-ansible: Update org [Sandro Bonazzola] ovirt-setup-lib: branched for 4.3 development [Sandro Bonazzola] ovirt-guest-agent: re-align [Nir Soffer] ioprocess: Add project for 4.2 [Martin Sivak] Cleanup and prepare SLA packages for 4.2 ------------------------------------------ Started by timer [EnvInject] - Loading node environment variables. Building remotely on mirrors.phx.ovirt.org (mirrors) in workspace <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-updates-el7-x86_64/…> > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url http://gerrit.ovirt.org/jenkins.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 Pruning obsolete local branches Fetching upstream changes from http://gerrit.ovirt.org/jenkins.git > git --version # timeout=10 > git fetch --tags --progress http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/* --prune > git rev-parse origin/master^{commit} # timeout=10 Checking out Revision 1b9164a35a85fde7ff0218fa6cacfed04472e381 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 1b9164a35a85fde7ff0218fa6cacfed04472e381 Commit message: "Cleanup and prepare SLA packages for 4.2" > git rev-list 7884783969141c572c6a8fd1331a612ecfa542ac # timeout=10 [system-sync_mirrors-centos-updates-el7-x86_64] $ /bin/bash -xe /tmp/jenkins5771763202377004232.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror centos-updates-el7 x86_64 jenkins/data/mirrors-reposync.conf Checking if mirror needs a resync Traceback (most recent call last): File "/usr/bin/reposync", line 343, in <module> main() File "/usr/bin/reposync", line 175, in main my.doRepoSetup() File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 681, in doRepoSetup return self._getRepos(thisrepo, True) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 721, in _getRepos self._repos.doSetup(thisrepo) File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, in doSetup self.retrieveAllMD() File "/usr/lib/python2.7/site-packages/yum/repos.py", line 88, in retrieveAllMD dl = repo._async and repo._commonLoadRepoXML(repo) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1465, in _commonLoadRepoXML local = self.cachedir + '/repomd.xml' File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 774, in <lambda> cachedir = property(lambda self: self._dirGetAttr('cachedir')) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 757, in _dirGetAttr self.dirSetup() File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 735, in dirSetup self._dirSetupMkdir_p(dir) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 712, in _dirSetupMkdir_p raise Errors.RepoError, msg yum.Errors.RepoError: Error making cache directory: /home/jenkins/mirrors_cache/centos-updates-el7/gen error was: [Errno 17] File exists: '/home/jenkins/mirrors_cache/centos-updates-el7/gen' Build step 'Execute shell' marked build as failure

1 1

oVirt infra weekly meeting notes 31.01.2018
by Evgheni Dereveanchin 31 Jan '18

31 Jan '18

Hi everyone, Please find the topics of this week's infra meeting below: PHX DC - Core network equipment change completed on Monday - Repo definitions removed from puppet as part of OVIRT-1810 <https://ovirt-jira.atlassian.net/browse/OVIRT-1810> - New Fedora 27 snapshot enabled to fix GDBM issue OVIRT-1839 <https://ovirt-jira.atlassian.net/browse/OVIRT-1839> - Issue with lago port taken on slaves showing up again OVIRT-1712 <https://ovirt-jira.atlassian.net/browse/OVIRT-1712> - Disk filling on templates.ovirt.org OVIRT-1869 <https://ovirt-jira.atlassian.net/browse/OVIRT-1869> - Kubevirt jobs take up slaves -> open ticket - Jenkins update tested on Staging OVIRT-1858 <https://ovirt-jira.atlassian.net/browse/OVIRT-1858> AI - Import CoreOS to glance -- Regards, Evgheni Dereveanchin

1 0

[CQ]: 83154,4 (ovirt-engine-wildfly) failed "ovirt-4.2" system tests
by oVirt Jenkins 31 Jan '18

31 Jan '18

Change 83154,4 (ovirt-engine-wildfly) is probably the reason behind recent system test failures in the "ovirt-4.2" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/83154/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/385/

1 0

[JIRA] (OST-99) new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium
by eyal edri (oVirt JIRA) 31 Jan '18

31 Jan '18

This is a multi-part message in MIME format... ------------=_1517412734-27111-145 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OST-99?page=com.atlassian.jira.plug… ] eyal edri moved OVIRT-1788 to OST-99: ------------------------------------- Component/s: (was: OST) Project: oVirt system tests (was: oVirt - virtualization made easy) Workflow: Software Simplified Workflow for Project OST (was: Task Management Workflow) Key: OST-99 (was: OVIRT-1788) > new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium > ------------------------------------------------------------------------------ > > Key: OST-99 > URL: https://ovirt-jira.atlassian.net/browse/OST-99 > Project: oVirt system tests > Issue Type: Improvement > Reporter: Greg Sheremeta > Assignee: infra > > I'm writing a suite that does headless UI testing. One goal is to open headless firefox and actually open the UI, perform a login, make sure things look good, make sure there are no ui.log errors, etc. I'll also eventually add chromium, which can run headless now too. > The suite requires several firefox versions to be installed on the test machine, along with chromium. There are also some binary components required, geckodriver and chromedriver. These are not packaged. > Ideally the browsers can be installed to /opt/firefox55, /opt/firefox56, /opt/chromium62, etc. on the machine running the suite. So I think it makes sense to maintain a custom rpm with all of this. > Where can this rpm live? What is a reliable way to do this? (I know we want to avoid copr.) -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077) ------------=_1517412734-27111-145 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OST-99?page=com.atlassian.jira.plug… ]</pre> <h3>eyal edri moved OVIRT-1788 to OST-99:</h3> <pre> Component/s: (was: OST) Project: oVirt system tests (was: oVirt - virtualization made easy) Workflow: Software Simplified Workflow for Project OST (was: Task Management Workflow) Key: OST-99 (was: OVIRT-1788)</pre> <blockquote><h3>new ui_sanity scenario for basic_suite — need multiple firefoxes and chromium</h3> <pre> Key: OST-99 URL: https://ovirt-jira.atlassian.net/browse/OST-99 Project: oVirt system tests Issue Type: Improvement Reporter: Greg Sheremeta Assignee: infra</pre> <p>I'm writing a suite that does headless UI testing. One goal is to open headless firefox and actually open the UI, perform a login, make sure things look good, make sure there are no ui.log errors, etc. I'll also eventually add chromium, which can run headless now too. The suite requires several firefox versions to be installed on the test machine, along with chromium. There are also some binary components required, geckodriver and chromedriver. These are not packaged. Ideally the browsers can be installed to /opt/firefox55, /opt/firefox56, /opt/chromium62, etc. on the machine running the suite. So I think it makes sense to maintain a custom rpm with all of this. Where can this rpm live? What is a reliable way to do this? (I know we want to avoid copr.)</p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1517412734-27111-145--

1 0

[CQ]: 86940, 3 (ovirt-setup-lib) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 31 Jan '18

31 Jan '18

A system test invoked by the "ovirt-4.2" change queue including change 86940,3 (ovirt-setup-lib) failed. However, this change seems not to be the root cause for this failure. Change 86938,2 (ovirt-setup-lib) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86938,2 (ovirt-setup-lib) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86940/3 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86938/2 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/383/

1 0

[CQ]: 86944,1 (ioprocess) failed "ovirt-master" system tests
by oVirt Jenkins 31 Jan '18

31 Jan '18

Change 86944,1 (ioprocess) is probably the reason behind recent system test failures in the "ovirt-master" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/86944/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5175/

1 0

[JIRA] (OVIRT-1712) OST jobs fails on "address already in use"
by eyal edri (oVirt JIRA) 31 Jan '18

31 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1712?page=com.atlassian.jira.… ] eyal edri commented on OVIRT-1712: ---------------------------------- So what is the alternate fix? > OST jobs fails on "address already in use" > ------------------------------------------ > > Key: OVIRT-1712 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1712 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: eyal edri > Assignee: Gal Ben Haim > Priority: High > > Evgheni, > Was there any change recently to Lago slaves? > On Fri, Oct 20, 2017 at 11:05 AM, Piotr Kliczewski < > piotr.kliczewski(a)gmail.com> wrote: > > I attempted to run manual OST twice and both failed with below issue. > > Can someone take a look? > > > > Thanks, > > Piotr > > > > 2017-10-20 07:59:12,485::log_utils.py::__exit__::607::ovirtlago.prefix: > > :DEBUG:: > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > > > 2017-10-20 07:59:12,485::cmd.py::do_run::365::root::ERROR::Error > > occured, aborting > > Traceback (most recent call last): > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 362, in > > do_run > > self.cli_plugins[args.ovirtverb].do_run(args) > > File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line > > 184, in do_run > > self._do_run(**vars(args)) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 501, in > > wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 512, in > > wrapper > > return func(*args, prefix=prefix, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 166, > > in do_deploy > > prefix.deploy() > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > error: [Errno 98] Address already in use > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > -- > Eyal edri > MANAGER > RHV DevOps > EMEA VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > phone: +972-9-7692018 > irc: eedri (on #tlv #rhev-dev #rhev-integ) -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1712) OST jobs fails on "address already in use"
by Daniel Belenky (oVirt JIRA) 31 Jan '18

31 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1712?page=com.atlassian.jira.… ] Daniel Belenky commented on OVIRT-1712: --------------------------------------- We've abandoned the fix from mock_runner's side for now > OST jobs fails on "address already in use" > ------------------------------------------ > > Key: OVIRT-1712 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1712 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: eyal edri > Assignee: Gal Ben Haim > Priority: High > > Evgheni, > Was there any change recently to Lago slaves? > On Fri, Oct 20, 2017 at 11:05 AM, Piotr Kliczewski < > piotr.kliczewski(a)gmail.com> wrote: > > I attempted to run manual OST twice and both failed with below issue. > > Can someone take a look? > > > > Thanks, > > Piotr > > > > 2017-10-20 07:59:12,485::log_utils.py::__exit__::607::ovirtlago.prefix: > > :DEBUG:: > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > > > 2017-10-20 07:59:12,485::cmd.py::do_run::365::root::ERROR::Error > > occured, aborting > > Traceback (most recent call last): > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 362, in > > do_run > > self.cli_plugins[args.ovirtverb].do_run(args) > > File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line > > 184, in do_run > > self._do_run(**vars(args)) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 501, in > > wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 512, in > > wrapper > > return func(*args, prefix=prefix, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 166, > > in do_deploy > > prefix.deploy() > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > error: [Errno 98] Address already in use > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > -- > Eyal edri > MANAGER > RHV DevOps > EMEA VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > phone: +972-9-7692018 > irc: eedri (on #tlv #rhev-dev #rhev-integ) -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1712) OST jobs fails on "address already in use"
by eyal edri (oVirt JIRA) 31 Jan '18

31 Jan '18

This is a multi-part message in MIME format... ------------=_1517408202-32693-199 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1712?page=com.atlassian.jira.… ] eyal edri commented on OVIRT-1712: ---------------------------------- [~dbelenky@redhat.com][~gbenhaim@redhat.com] what was the latest fix on this issue? did we abandon the fix on mock runner ? is there a plan to fix it from lago side? > OST jobs fails on "address already in use" > ------------------------------------------ > > Key: OVIRT-1712 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1712 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: eyal edri > Assignee: Gal Ben Haim > Priority: High > > Evgheni, > Was there any change recently to Lago slaves? > On Fri, Oct 20, 2017 at 11:05 AM, Piotr Kliczewski < > piotr.kliczewski(a)gmail.com> wrote: > > I attempted to run manual OST twice and both failed with below issue. > > Can someone take a look? > > > > Thanks, > > Piotr > > > > 2017-10-20 07:59:12,485::log_utils.py::__exit__::607::ovirtlago.prefix: > > :DEBUG:: > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > > > 2017-10-20 07:59:12,485::cmd.py::do_run::365::root::ERROR::Error > > occured, aborting > > Traceback (most recent call last): > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 362, in > > do_run > > self.cli_plugins[args.ovirtverb].do_run(args) > > File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line > > 184, in do_run > > self._do_run(**vars(args)) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 501, in > > wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 512, in > > wrapper > > return func(*args, prefix=prefix, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 166, > > in do_deploy > > prefix.deploy() > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > error: [Errno 98] Address already in use > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > -- > Eyal edri > MANAGER > RHV DevOps > EMEA VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > phone: +972-9-7692018 > irc: eedri (on #tlv #rhev-dev #rhev-integ) -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077) ------------=_1517408202-32693-199 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1712?page=com.atlassian.jira.… ]</pre> <h3>eyal edri commented on OVIRT-1712:</h3> <p>[~dbelenky@redhat.com][~gbenhaim@redhat.com] what was the latest fix on this issue? did we abandon the fix on mock runner ? is there a plan to fix it from lago side?</p> <blockquote><h3>OST jobs fails on “address already in use”</h3> <pre> Key: OVIRT-1712 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1712 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: eyal edri Assignee: Gal Ben Haim Priority: High</pre> <p>Evgheni, Was there any change recently to Lago slaves? On Fri, Oct 20, 2017 at 11:05 AM, Piotr Kliczewski < piotr.kliczewski(a)gmail.com> wrote:</p> <blockquote><p>I attempted to run manual OST twice and both failed with below issue. Can someone take a look?</p> <p>Thanks, Piotr</p> <p>2017-10-20 07:59:12,485::log_utils.py::__exit__::607::ovirtlago.prefix: :DEBUG::</p> <pre>File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636,</pre> <p>in wrapper</p> <pre> return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line</pre> <p>111, in wrapper</p> <pre> with utils.repo_server_context(args[0]): File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ return self.gen.next() File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line</pre> <p>100, in repo_server_context</p> <pre> root_dir=prefix.paths.internal_repo(), File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76,</pre> <p>in _create_http_server</p> <pre> generate_request_handler(root_dir), File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ self.server_bind() File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind SocketServer.TCPServer.server_bind(self) File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind self.socket.bind(self.server_address) File "/usr/lib64/python2.7/socket.py", line 224, in meth return getattr(self._sock,name)(*args)</pre> <p>2017-10-20 07:59:12,485::cmd.py::do_run::365::root::ERROR::Error occured, aborting Traceback (most recent call last):</p> <pre>File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 362, in</pre> <p>do_run</p> <pre> self.cli_plugins[args.ovirtverb].do_run(args) File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line</pre> <p>184, in do_run</p> <pre> self._do_run(**vars(args)) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 501, in</pre> <p>wrapper</p> <pre> return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 512, in</pre> <p>wrapper</p> <pre> return func(*args, prefix=prefix, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 166,</pre> <p>in do_deploy</p> <pre> prefix.deploy() File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636,</pre> <p>in wrapper</p> <pre> return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line</pre> <p>111, in wrapper</p> <pre> with utils.repo_server_context(args[0]): File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ return self.gen.next() File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line</pre> <p>100, in repo_server_context</p> <pre> root_dir=prefix.paths.internal_repo(), File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76,</pre> <p>in _create_http_server</p> <pre> generate_request_handler(root_dir), File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ self.server_bind() File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind SocketServer.TCPServer.server_bind(self) File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind self.socket.bind(self.server_address) File "/usr/lib64/python2.7/socket.py", line 224, in meth return getattr(self._sock,name)(*args)</pre> <p>error: [Errno 98] Address already in use <em>____________________________________________</em>_ Infra mailing list Infra(a)ovirt.org <a href="http://lists.ovirt.org/mailman/listinfo/infra">http://lists.ovirt.org/mailman/listinfo/infra</a></p></blockquote> <p>— Eyal edri MANAGER RHV DevOps EMEA VIRTUALIZATION R&D Red Hat EMEA <<a href="https://www.redhat.com/">https://www.redhat.com/</a>> <<a href="https://red.ht/sig">https://red.ht/sig</a>> TRIED. TESTED. TRUSTED. <<a href="https://redhat.com/trusted">https://redhat.com/trusted</a>> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)</p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1517408202-32693-199--

1 0

[JIRA] (OVIRT-1712) OST jobs fails on "address already in use"
by Dafna Ron (oVirt JIRA) 31 Jan '18

31 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1712?page=com.atlassian.jira.… ] Dafna Ron commented on OVIRT-1712: ---------------------------------- We had 2 failures today on network in use. in the latest one I can see that the build that ran before failed on libvirt issue. Here is the failed build: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5173/ Here is the build that failed before: http://jenkins.ovirt.org/computer/ovirt-srv17.phx.ovirt.org/builds This is the host: http://jenkins.ovirt.org/computer/ovirt-srv17.phx.ovirt.org/ > OST jobs fails on "address already in use" > ------------------------------------------ > > Key: OVIRT-1712 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1712 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: eyal edri > Assignee: Gal Ben Haim > Priority: High > > Evgheni, > Was there any change recently to Lago slaves? > On Fri, Oct 20, 2017 at 11:05 AM, Piotr Kliczewski < > piotr.kliczewski(a)gmail.com> wrote: > > I attempted to run manual OST twice and both failed with below issue. > > Can someone take a look? > > > > Thanks, > > Piotr > > > > 2017-10-20 07:59:12,485::log_utils.py::__exit__::607::ovirtlago.prefix: > > :DEBUG:: > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > > > 2017-10-20 07:59:12,485::cmd.py::do_run::365::root::ERROR::Error > > occured, aborting > > Traceback (most recent call last): > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 362, in > > do_run > > self.cli_plugins[args.ovirtverb].do_run(args) > > File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line > > 184, in do_run > > self._do_run(**vars(args)) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 501, in > > wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 512, in > > wrapper > > return func(*args, prefix=prefix, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 166, > > in do_deploy > > prefix.deploy() > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > error: [Errno 98] Address already in use > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > -- > Eyal edri > MANAGER > RHV DevOps > EMEA VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > phone: +972-9-7692018 > irc: eedri (on #tlv #rhev-dev #rhev-integ) -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1869) add new disk to templates.ovirt.org
by Evgheni Dereveanchin (oVirt JIRA) 31 Jan '18

31 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1869?page=com.atlassian.jira.… ] Evgheni Dereveanchin reassigned OVIRT-1869: ------------------------------------------- Assignee: Evgheni Dereveanchin (was: infra) > add new disk to templates.ovirt.org > ----------------------------------- > > Key: OVIRT-1869 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1869 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Evgheni Dereveanchin > Assignee: Evgheni Dereveanchin > > We need to mount /var/www/html/bundles as a separate filesystem, same as we do for /var/www/html/repo on the templates file server. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1869) add new disk to templates.ovirt.org
by Evgheni Dereveanchin (oVirt JIRA) 31 Jan '18

31 Jan '18

Evgheni Dereveanchin created OVIRT-1869: ------------------------------------------- Summary: add new disk to templates.ovirt.org Key: OVIRT-1869 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1869 Project: oVirt - virtualization made easy Issue Type: Task Reporter: Evgheni Dereveanchin Assignee: infra We need to mount /var/www/html/bundles as a separate filesystem, same as we do for /var/www/html/repo on the templates file server. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[CQ]: 86912,2 (ovirt-engine) failed "ovirt-master" system tests
by oVirt Jenkins 31 Jan '18

31 Jan '18

Change 86912,2 (ovirt-engine) is probably the reason behind recent system test failures in the "ovirt-master" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/86912/2 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5173/

1 0

[CQ]: 86859, 3 (ovirt-engine-api-model) failed "ovirt-master" system tests
by oVirt Jenkins 31 Jan '18

31 Jan '18

Change 86859,3 (ovirt-engine-api-model) is probably the reason behind recent system test failures in the "ovirt-master" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/86859/3 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5170/

1 0

[CQ]: 85206,1 (ovirt-iso-uploader) failed "ovirt-4.2" system tests
by oVirt Jenkins 31 Jan '18

31 Jan '18

Change 85206,1 (ovirt-iso-uploader) is probably the reason behind recent system test failures in the "ovirt-4.2" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/85206/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/380/

1 0

[CQ]: 86951, 1 (ovirt-engine-api-model) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 31 Jan '18

31 Jan '18

A system test invoked by the "ovirt-4.2" change queue including change 86951,1 (ovirt-engine-api-model) failed. However, this change seems not to be the root cause for this failure. Change 86692,1 (ovirt-engine-api-model) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86692,1 (ovirt-engine-api- model) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86951/1 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86692/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/379/

1 0

[CQ]: 86950, 1 (ovirt-engine-api-model) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 31 Jan '18

31 Jan '18

A system test invoked by the "ovirt-4.2" change queue including change 86950,1 (ovirt-engine-api-model) failed. However, this change seems not to be the root cause for this failure. Change 86692,1 (ovirt-engine-api-model) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86692,1 (ovirt-engine-api- model) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86950/1 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86692/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/377/

1 0

[oVirt Jenkins] ovirt-system-tests_he-basic-ansible-suite-master - Build # 20 - Failure!
by jenkins＠jenkins.phx.ovirt.org 31 Jan '18

31 Jan '18

------=_Part_420_2006938412.1517279453385 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-ansible-suite-mast… Build: http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-ansible-suite-mast… Build Number: 20 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #20 [Roy Golan] perf-suite: log rotate more frequently [Barak Korren] Make standard-enqueue support non-ovirt queues [Barak Korren] Allow customizing CQ mail addresses [Barak Korren] Enable customizing the server we deploy tested to [Barak Korren] Make pipeline-loader support upstream sources [Barak Korren] Made clone url for 'jenkins' customizable ----------------- Failed Tests: ----------------- No tests ran. ------=_Part_420_2006938412.1517279453385--

1 1

[CQ]: 86939, 3 (ovirt-setup-lib) failed "ovirt-4.1" system tests, but isn't the failure root cause
by oVirt Jenkins 30 Jan '18

30 Jan '18

A system test invoked by the "ovirt-4.1" change queue including change 86939,3 (ovirt-setup-lib) failed. However, this change seems not to be the root cause for this failure. Change 86938,2 (ovirt-setup-lib) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86938,2 (ovirt-setup-lib) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86939/3 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86938/2 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1553/

1 0

[CQ]: 86939, 3 (ovirt-setup-lib) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 30 Jan '18

30 Jan '18

A system test invoked by the "ovirt-4.2" change queue including change 86939,3 (ovirt-setup-lib) failed. However, this change seems not to be the root cause for this failure. Change 86938,2 (ovirt-setup-lib) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86938,2 (ovirt-setup-lib) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86939/3 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86938/2 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/375/

1 0

[CQ]: 86938,2 (ovirt-setup-lib) failed "ovirt-4.1" system tests
by oVirt Jenkins 30 Jan '18

30 Jan '18

Change 86938,2 (ovirt-setup-lib) is probably the reason behind recent system test failures in the "ovirt-4.1" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/86938/2 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1552/

1 0

[CQ]: 86938,2 (ovirt-setup-lib) failed "ovirt-4.2" system tests
by oVirt Jenkins 30 Jan '18

30 Jan '18

Change 86938,2 (ovirt-setup-lib) is probably the reason behind recent system test failures in the "ovirt-4.2" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/86938/2 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/374/

1 0

[CQ]: 86913,2 (ovirt-engine) failed "ovirt-master" system tests
by oVirt Jenkins 30 Jan '18

30 Jan '18

Change 86913,2 (ovirt-engine) is probably the reason behind recent system test failures in the "ovirt-master" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/86913/2 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5164/

1 0

[JIRA] (OVIRT-1867) Allow embedded secrets inside the source repo for CI
by Barak Korren (oVirt JIRA) 30 Jan '18

30 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-1867: ------------------------------------- [~rmohr(a)redhat.com] the main issue I have with the concept you suggest is that it chains the code to a specific instance of the CI system. The point of STDCI is to be a standard - you can take a compliant project and build/test it the same way on different CI systems. They way you suggest to handle secrets - it essentially chains the project to a specific CI system instance - the one that knows the right private key. This concept makes perfect sense for PAAS providers like Travis that want to lock you into the single instance their platform... Our view of credentials is also slightly different - instead of a developer providing his own credentials for using service X, he just asks for access for service X, and it becomes the CI system's responsibility to figure out how to provide access to that service. Having said the above, implementing what you ask for is not difficult, so we may add this soon as an additional feature for our existing credentials support. The main challenge would be to find where to store all the private keys and provide access to the public keys. Our system doesn't really have a UI that is not linked to a specific build/test run, since so far the assumption has always been that all communication with the CI system is done via commits or comments to the SCM. > Allow embedded secrets inside the source repo for CI > ---------------------------------------------------- > > Key: OVIRT-1867 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Standard CI (Pipelines), STDCI DSL > Reporter: Roman Mohr > Assignee: infra > > In order to improve the self-service capabilities of standard-ci it is > important for projects, that they can add their own secrets to projects (to > reach external services, e.g. docker hub, ...). > Travis has a very nice system which helps engineers there: > https://docs.travis-ci.com/user/encryption-keys/ > Basically the CI system needs to generate a public/private key pair for > every enabled git repo. The engineer simply fetches the public key via a > well know URL and encrypts the secrets. Then the encrypted secret can be > made part of the source repo. Before the tests are run the CI system > decrypts the secrets. Than can play together pretty well with Jenkinsfiles > too. > Benefit: > * Less manual intervention from CI team to add secrets to jobs > * Strengthen the config-in-code thinking -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

Build failed in Jenkins: system-sync_mirrors-centos-updates-el7-x86_64 #1224
by jenkins＠jenkins.phx.ovirt.org 30 Jan '18

30 Jan '18

See <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-updates-el7-x86_64/…> Changes: [Sandro Bonazzola] copy-create-job: drop EOLed Fedoras [Dafna Ron] otopi - dropping fc24 [Dafna Ron] ovirt-hosted-engine-setup - dropping fc24 [Daniel Belenky] Mock runner to search full script path [Sandro Bonazzola] otopi: 4.2 and latest fedora [Sandro Bonazzola] ovirt-hosted-engine-setup: 4.2 and new Fedoras [Sandro Bonazzola] ovirt-live: drop project ------------------------------------------ Started by timer [EnvInject] - Loading node environment variables. Building remotely on mirrors.phx.ovirt.org (mirrors) in workspace <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-updates-el7-x86_64/…> > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url http://gerrit.ovirt.org/jenkins.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 Pruning obsolete local branches Fetching upstream changes from http://gerrit.ovirt.org/jenkins.git > git --version # timeout=10 > git fetch --tags --progress http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/* --prune > git rev-parse origin/master^{commit} # timeout=10 Checking out Revision 453d3f78c51516ce19b686b9ac141d2ced2260d7 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 453d3f78c51516ce19b686b9ac141d2ced2260d7 Commit message: "ovirt-live: drop project" > git rev-list ffe020fb18b7f872bc817ba9eec0c0d5a82bc489 # timeout=10 [system-sync_mirrors-centos-updates-el7-x86_64] $ /bin/bash -xe /tmp/jenkins4363023534009612747.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror centos-updates-el7 x86_64 jenkins/data/mirrors-reposync.conf Checking if mirror needs a resync Traceback (most recent call last): File "/usr/bin/reposync", line 343, in <module> main() File "/usr/bin/reposync", line 175, in main my.doRepoSetup() File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 681, in doRepoSetup return self._getRepos(thisrepo, True) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 721, in _getRepos self._repos.doSetup(thisrepo) File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, in doSetup self.retrieveAllMD() File "/usr/lib/python2.7/site-packages/yum/repos.py", line 112, in retrieveAllMD repo._revertOldRepoXML() File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1331, in _revertOldRepoXML os.rename(old_data['old_local'], old_data['local']) OSError: [Errno 2] No such file or directory Build step 'Execute shell' marked build as failure

1 1

[JIRA] (OVIRT-1867) Allow embedded secrets inside the source repo for CI
by Barak Korren (oVirt JIRA) 30 Jan '18

30 Jan '18

This is a multi-part message in MIME format... ------------=_1517318718-26640-235 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1867: -------------------------------- Epic Link: OVIRT-400 Issue Type: New Feature (was: By-EMAIL) > Allow embedded secrets inside the source repo for CI > ---------------------------------------------------- > > Key: OVIRT-1867 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Standard CI (Pipelines), STDCI DSL > Reporter: Roman Mohr > Assignee: infra > > In order to improve the self-service capabilities of standard-ci it is > important for projects, that they can add their own secrets to projects (to > reach external services, e.g. docker hub, ...). > Travis has a very nice system which helps engineers there: > https://docs.travis-ci.com/user/encryption-keys/ > Basically the CI system needs to generate a public/private key pair for > every enabled git repo. The engineer simply fetches the public key via a > well know URL and encrypts the secrets. Then the encrypted secret can be > made part of the source repo. Before the tests are run the CI system > decrypts the secrets. Than can play together pretty well with Jenkinsfiles > too. > Benefit: > * Less manual intervention from CI team to add secrets to jobs > * Strengthen the config-in-code thinking -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077) ------------=_1517318718-26640-235 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jira.… ]</pre> <h3>Barak Korren updated OVIRT-1867:</h3> <pre> Epic Link: OVIRT-400 Issue Type: New Feature (was: By-EMAIL)</pre> <blockquote><h3>Allow embedded secrets inside the source repo for CI</h3> <pre> Key: OVIRT-1867 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 Project: oVirt - virtualization made easy Issue Type: New Feature Components: Standard CI (Pipelines), STDCI DSL Reporter: Roman Mohr Assignee: infra</pre> <p>In order to improve the self-service capabilities of standard-ci it is important for projects, that they can add their own secrets to projects (to reach external services, e.g. docker hub, …). Travis has a very nice system which helps engineers there: <a href="https://docs.travis-ci.com/user/encryption-keys/">https://docs.travis-ci.com/user/encryption-keys/</a> Basically the CI system needs to generate a public/private key pair for every enabled git repo. The engineer simply fetches the public key via a well know URL and encrypts the secrets. Then the encrypted secret can be made part of the source repo. Before the tests are run the CI system decrypts the secrets. Than can play together pretty well with Jenkinsfiles too. Benefit:</p> <pre>* Less manual intervention from CI team to add secrets to jobs * Strengthen the config-in-code thinking</pre></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1517318718-26640-235--

1 0

[JIRA] (OVIRT-1867) Allow embedded secrets inside the source repo for CI
by Barak Korren (oVirt JIRA) 30 Jan '18

30 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1867: -------------------------------- Epic Link: OVIRT-400 > Allow embedded secrets inside the source repo for CI > ---------------------------------------------------- > > Key: OVIRT-1867 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Components: Standard CI (Pipelines), STDCI DSL > Reporter: Roman Mohr > Assignee: infra > > In order to improve the self-service capabilities of standard-ci it is > important for projects, that they can add their own secrets to projects (to > reach external services, e.g. docker hub, ...). > Travis has a very nice system which helps engineers there: > https://docs.travis-ci.com/user/encryption-keys/ > Basically the CI system needs to generate a public/private key pair for > every enabled git repo. The engineer simply fetches the public key via a > well know URL and encrypts the secrets. Then the encrypted secret can be > made part of the source repo. Before the tests are run the CI system > decrypts the secrets. Than can play together pretty well with Jenkinsfiles > too. > Benefit: > * Less manual intervention from CI team to add secrets to jobs > * Strengthen the config-in-code thinking -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1868) Allow engineers to write Jenkinsfiles
by Barak Korren (oVirt JIRA) 30 Jan '18

30 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1868?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1868: -------------------------------- Component/s: Standard CI (Pipelines) > Allow engineers to write Jenkinsfiles > ------------------------------------- > > Key: OVIRT-1868 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1868 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Standard CI (Pipelines) > Reporter: Roman Mohr > Assignee: infra > > Looks like standard-ci switched internally to use Jenkinsfiles. However it > would be very valuable for engineers, if they could just write their > Jenkinsfile, instead of all the usual standard-ci yamls/scripts. > With the Jenkinsfile the chroot based approach seems to be pretty obsolete, > if you allow people to use the docker agent for the Jenkinsfile. For > KubeVirt it would make standard-ci finally really valuable. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1868) Allow engineers to write Jenkinsfiles
by Barak Korren (oVirt JIRA) 30 Jan '18

30 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1868?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1868: -------------------------------- Epic Link: OVIRT-400 > Allow engineers to write Jenkinsfiles > ------------------------------------- > > Key: OVIRT-1868 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1868 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Reporter: Roman Mohr > Assignee: infra > > Looks like standard-ci switched internally to use Jenkinsfiles. However it > would be very valuable for engineers, if they could just write their > Jenkinsfile, instead of all the usual standard-ci yamls/scripts. > With the Jenkinsfile the chroot based approach seems to be pretty obsolete, > if you allow people to use the docker agent for the Jenkinsfile. For > KubeVirt it would make standard-ci finally really valuable. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1868) Allow engineers to write Jenkinsfiles
by Barak Korren (oVirt JIRA) 30 Jan '18

30 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1868?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1868: -------------------------------- Epic Link: OVIRT-400 > Allow engineers to write Jenkinsfiles > ------------------------------------- > > Key: OVIRT-1868 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1868 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Reporter: Roman Mohr > Assignee: infra > > Looks like standard-ci switched internally to use Jenkinsfiles. However it > would be very valuable for engineers, if they could just write their > Jenkinsfile, instead of all the usual standard-ci yamls/scripts. > With the Jenkinsfile the chroot based approach seems to be pretty obsolete, > if you allow people to use the docker agent for the Jenkinsfile. For > KubeVirt it would make standard-ci finally really valuable. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1868) Allow engineers to write Jenkinsfiles
by Barak Korren (oVirt JIRA) 30 Jan '18

30 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1868?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1868: -------------------------------- Issue Type: New Feature (was: By-EMAIL) > Allow engineers to write Jenkinsfiles > ------------------------------------- > > Key: OVIRT-1868 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1868 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Reporter: Roman Mohr > Assignee: infra > > Looks like standard-ci switched internally to use Jenkinsfiles. However it > would be very valuable for engineers, if they could just write their > Jenkinsfile, instead of all the usual standard-ci yamls/scripts. > With the Jenkinsfile the chroot based approach seems to be pretty obsolete, > if you allow people to use the docker agent for the Jenkinsfile. For > KubeVirt it would make standard-ci finally really valuable. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1868) Allow engineers to write Jenkinsfiles
by Barak Korren (oVirt JIRA) 30 Jan '18

30 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1868?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-1868: ------------------------------------- {quote} Looks like standard-ci switched internally to use Jenkinsfiles. However it would be very valuable for engineers, if they could just write their Jenkinsfile, instead of all the usual standard-ci yamls/scripts. {quote} We use pipelines - Jenkinfiles are pipeline-based but also impose a very specific workflow, while generic pipelines are far more flexible. {quote} With the Jenkinsfile the chroot based approach seems to be pretty obsolete, {quote} Nope,there are quite a few things the current approach makes easy to do that Jenkinsfile would make complex or impossible. The main point of the current approach is not the use of mock/chroot, which is an implementation detail, but the use of a standardized generic configuration format, where different backends could be implemented. It allows the CI team to deal effectively with how CI resources are distributed and managed while allowing developers to just specify what they need. With Jenkinsfile the developers would have to deal with a lot of the mechanics or resource allocation and management, while the CI team will be unable to control how resources are used or to ensure they are returned to usable state when jobs finish. The configuration formal also allows the CI system to gain a good knowledge about the dependencies for a given test/build process. This allows it to to control how and which versions of these dependencies are provided. (For example, when you ask for yum repositories, the CI system ensure you get the same view of these repositories from the point in time in which the jobs started, even if they get updated while the job is running). Jenkinsfile, as it stands, will also chain us to a very specific CI orchestration engine. Don't get me wrong, Jenkins is nice, but its good to know we can switch the backend and have that switch be mostly transparent to project developers. Its also very convenient to have a client-side mini-backend, it would be quite impossible to make such a backend for a Jenkinsfile. {quote} if you allow people to use the docker agent for the Jenkinsfile. For KubeVirt it would make standard-ci finally really valuable. {quote} STDCI have been quite valuable so far TYVM. Using the docker agent as you suggest will actually make it lees so because it will chain you to a very specific method of resource allocation. It will make it harder to do things like ensure a certain test script gets its own bare-metal machine to run on. Docker containers are useful - but many people couldn't care less, they just know they need to target 'el7' and need a few dependencies for that, forcing then to then deal with finding or making a suitable container image will just divert efforts from the more important work of writing the actual code to be tested. The main thing that Jenkinsfiles have to offer that STDCI does not support currently is the ability to sequentially chain multiple steps together and have control flow to decide which steps get executed. We are going to make STDCI provide that, and we're going to try to do that in a syntax that would be familiar to anyone who is familiar with Jenkinsfiles. But it is going to be a subset of the Jenkinsfie syntax. Things like node() for example, are probably not going to be supported since STDCI already provides higher-level ways of requesting node allocation. > Allow engineers to write Jenkinsfiles > ------------------------------------- > > Key: OVIRT-1868 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1868 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Roman Mohr > Assignee: infra > > Looks like standard-ci switched internally to use Jenkinsfiles. However it > would be very valuable for engineers, if they could just write their > Jenkinsfile, instead of all the usual standard-ci yamls/scripts. > With the Jenkinsfile the chroot based approach seems to be pretty obsolete, > if you allow people to use the docker agent for the Jenkinsfile. For > KubeVirt it would make standard-ci finally really valuable. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[CQ]: 86903, 1 (ovirt-engine-api-model) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 30 Jan '18

30 Jan '18

A system test invoked by the "ovirt-4.2" change queue including change 86903,1 (ovirt-engine-api-model) failed. However, this change seems not to be the root cause for this failure. Change 86692,1 (ovirt-engine-api-model) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86692,1 (ovirt-engine-api- model) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86903/1 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86692/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/372/

1 0

[JIRA] (OVIRT-1867) Allow embedded secrets inside the source repo for CI
by Roman Mohr (oVirt JIRA) 30 Jan '18

30 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jira.… ] Roman Mohr commented on OVIRT-1867: ----------------------------------- In my opinion, having the secrets encrypted in the code is better, since you don't need accounts for engineers on CI to do that. A public rsa key can be made accessible for the whole world. With other words, the issue is exactly about the self-service and not about how to bind existing secrets. It is also related to OVIRT-1868. In combination with a Jenkinsfile, pretty much the whole yaml/script/chroot can be made obsolete, however that is a different story. > Allow embedded secrets inside the source repo for CI > ---------------------------------------------------- > > Key: OVIRT-1867 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Components: Standard CI (Pipelines), STDCI DSL > Reporter: Roman Mohr > Assignee: infra > > In order to improve the self-service capabilities of standard-ci it is > important for projects, that they can add their own secrets to projects (to > reach external services, e.g. docker hub, ...). > Travis has a very nice system which helps engineers there: > https://docs.travis-ci.com/user/encryption-keys/ > Basically the CI system needs to generate a public/private key pair for > every enabled git repo. The engineer simply fetches the public key via a > well know URL and encrypts the secrets. Then the encrypted secret can be > made part of the source repo. Before the tests are run the CI system > decrypts the secrets. Than can play together pretty well with Jenkinsfiles > too. > Benefit: > * Less manual intervention from CI team to add secrets to jobs > * Strengthen the config-in-code thinking -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[CQ]: 86869, 1 (otopi) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 30 Jan '18

30 Jan '18

A system test invoked by the "ovirt-master" change queue including change 86869,1 (otopi) failed. However, this change seems not to be the root cause for this failure. Change 86679,4 (otopi) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86679,4 (otopi) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86869/1 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86679/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5160/

1 0

[JIRA] (OVIRT-1867) Allow embedded secrets inside the source repo for CI
by Daniel Belenky (oVirt JIRA) 30 Jan '18

30 Jan '18

This is a multi-part message in MIME format... ------------=_1517312708-12381-241 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jira.… ] Daniel Belenky updated OVIRT-1867: ---------------------------------- Component/s: STDCI DSL Standard CI (Pipelines) > Allow embedded secrets inside the source repo for CI > ---------------------------------------------------- > > Key: OVIRT-1867 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Components: Standard CI (Pipelines), STDCI DSL > Reporter: Roman Mohr > Assignee: infra > > In order to improve the self-service capabilities of standard-ci it is > important for projects, that they can add their own secrets to projects (to > reach external services, e.g. docker hub, ...). > Travis has a very nice system which helps engineers there: > https://docs.travis-ci.com/user/encryption-keys/ > Basically the CI system needs to generate a public/private key pair for > every enabled git repo. The engineer simply fetches the public key via a > well know URL and encrypts the secrets. Then the encrypted secret can be > made part of the source repo. Before the tests are run the CI system > decrypts the secrets. Than can play together pretty well with Jenkinsfiles > too. > Benefit: > * Less manual intervention from CI team to add secrets to jobs > * Strengthen the config-in-code thinking -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077) ------------=_1517312708-12381-241 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jira.… ]</pre> <h3>Daniel Belenky updated OVIRT-1867:</h3> <pre> Component/s: STDCI DSL Standard CI (Pipelines)</pre> <blockquote><h3>Allow embedded secrets inside the source repo for CI</h3> <pre> Key: OVIRT-1867 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Components: Standard CI (Pipelines), STDCI DSL Reporter: Roman Mohr Assignee: infra</pre> <p>In order to improve the self-service capabilities of standard-ci it is important for projects, that they can add their own secrets to projects (to reach external services, e.g. docker hub, …). Travis has a very nice system which helps engineers there: <a href="https://docs.travis-ci.com/user/encryption-keys/">https://docs.travis-ci.com/user/encryption-keys/</a> Basically the CI system needs to generate a public/private key pair for every enabled git repo. The engineer simply fetches the public key via a well know URL and encrypts the secrets. Then the encrypted secret can be made part of the source repo. Before the tests are run the CI system decrypts the secrets. Than can play together pretty well with Jenkinsfiles too. Benefit:</p> <pre>* Less manual intervention from CI team to add secrets to jobs * Strengthen the config-in-code thinking</pre></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1517312708-12381-241--

1 0

[JIRA] (OVIRT-1867) Allow embedded secrets inside the source repo for CI
by Daniel Belenky (oVirt JIRA) 30 Jan '18

30 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jira.… ] Daniel Belenky commented on OVIRT-1867: --------------------------------------- We actually have a mechanism for secrets as environmental variables in stdci. Currently, we hold the secrets in a single secret file on our Jenkins master, and engineers can request those secrets as environmental variables via *.environment.yaml. The syntax is the same as for Kubernetes: {code:java} --- - name: MY_VAR valueFrom: secretKeyRef: name: MySecret1 value: password {code} The example above will bind the password field from MySecret1 to $MY_VAR inside the chroot created by STDCI. The one part which is still missing though is a common interface to allow projects to add the secrets to this file automatically. > Allow embedded secrets inside the source repo for CI > ---------------------------------------------------- > > Key: OVIRT-1867 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Roman Mohr > Assignee: infra > > In order to improve the self-service capabilities of standard-ci it is > important for projects, that they can add their own secrets to projects (to > reach external services, e.g. docker hub, ...). > Travis has a very nice system which helps engineers there: > https://docs.travis-ci.com/user/encryption-keys/ > Basically the CI system needs to generate a public/private key pair for > every enabled git repo. The engineer simply fetches the public key via a > well know URL and encrypts the secrets. Then the encrypted secret can be > made part of the source repo. Before the tests are run the CI system > decrypts the secrets. Than can play together pretty well with Jenkinsfiles > too. > Benefit: > * Less manual intervention from CI team to add secrets to jobs > * Strengthen the config-in-code thinking -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1868) Allow engineers to write Jenkinsfiles
by Roman Mohr (oVirt JIRA) 30 Jan '18

30 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1868?page=com.atlassian.jira.… ] Roman Mohr updated OVIRT-1868: ------------------------------ Description: Looks like standard-ci switched internally to use Jenkinsfiles. However it would be very valuable for engineers, if they could just write their Jenkinsfile, instead of all the usual standard-ci yamls/scripts. With the Jenkinsfile the chroot based approach seems to be pretty obsolete, if you allow people to use the docker agent for the Jenkinsfile. For KubeVirt it would make standard-ci finally really valuable. was: Looks like standard-ci switched internally to use Jenkinsfiles. However it would be very valuable for engineers, if they could just write their Jenkinsfile, instead of all the usual standard-ci yamls/scripts. With the Jenkinsfile the chroot based approach seems to be pretty obsolate, if you allow people to use the docker agent for the Jenkinsfile. For KubeVirt it would make standard-ci finally really valuable. > Allow engineers to write Jenkinsfiles > ------------------------------------- > > Key: OVIRT-1868 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1868 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Roman Mohr > Assignee: infra > > Looks like standard-ci switched internally to use Jenkinsfiles. However it > would be very valuable for engineers, if they could just write their > Jenkinsfile, instead of all the usual standard-ci yamls/scripts. > With the Jenkinsfile the chroot based approach seems to be pretty obsolete, > if you allow people to use the docker agent for the Jenkinsfile. For > KubeVirt it would make standard-ci finally really valuable. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1868) Allow engineers to write Jenkinsfiles
by Roman Mohr (oVirt JIRA) 30 Jan '18

30 Jan '18

Roman Mohr created OVIRT-1868: --------------------------------- Summary: Allow engineers to write Jenkinsfiles Key: OVIRT-1868 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1868 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Roman Mohr Assignee: infra Looks like standard-ci switched internally to use Jenkinsfiles. However it would be very valuable for engineers, if they could just write their Jenkinsfile, instead of all the usual standard-ci yamls/scripts. With the Jenkinsfile the chroot based approach seems to be pretty obsolate, if you allow people to use the docker agent for the Jenkinsfile. For KubeVirt it would make standard-ci finally really valuable. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1867) Allow embedded secrets inside the source repo for CI
by Roman Mohr (oVirt JIRA) 30 Jan '18

30 Jan '18

This is a multi-part message in MIME format... ------------=_1517308592-17438-377 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Roman Mohr created OVIRT-1867: --------------------------------- Summary: Allow embedded secrets inside the source repo for CI Key: OVIRT-1867 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Roman Mohr Assignee: infra In order to improve the self-service capabilities of standard-ci it is important for projects, that they can add their own secrets to projects (to reach external services, e.g. docker hub, ...). Travis has a very nice system which helps engineers there: https://docs.travis-ci.com/user/encryption-keys/ Basically the CI system needs to generate a public/private key pair for every enabled git repo. The engineer simply fetches the public key via a well know URL and encrypts the secrets. Then the encrypted secret can be made part of the source repo. Before the tests are run the CI system decrypts the secrets. Than can play together pretty well with Jenkinsfiles too. Benefit: * Less manual intervention from CI team to add secrets to jobs * Strengthen the config-in-code thinking -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077) ------------=_1517308592-17438-377 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <h3>Roman Mohr created OVIRT-1867:</h3> <pre> Summary: Allow embedded secrets inside the source repo for CI Key: OVIRT-1867 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Roman Mohr Assignee: infra</pre> <p>In order to improve the self-service capabilities of standard-ci it is important for projects, that they can add their own secrets to projects (to reach external services, e.g. docker hub, …).</p> <p>Travis has a very nice system which helps engineers there: <a href="https://docs.travis-ci.com/user/encryption-keys/">https://docs.travis-ci.com/user/encryption-keys/</a></p> <p>Basically the CI system needs to generate a public/private key pair for every enabled git repo. The engineer simply fetches the public key via a well know URL and encrypts the secrets. Then the encrypted secret can be made part of the source repo. Before the tests are run the CI system decrypts the secrets. Than can play together pretty well with Jenkinsfiles too.</p> <p>Benefit:</p> <pre>* Less manual intervention from CI team to add secrets to jobs * Strengthen the config-in-code thinking</pre> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1517308592-17438-377--

1 0

[CQ]: 86910, 1 (ovirt-hosted-engine-setup) failed "ovirt-4.2" system tests
by oVirt Jenkins 30 Jan '18

30 Jan '18

Change 86910,1 (ovirt-hosted-engine-setup) is probably the reason behind recent system test failures in the "ovirt-4.2" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/86910/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/370/

1 0

[CQ]: e74f3bb (stage-gh-stdci2) failed "dummy-master" system tests, but isn't the failure root cause
by oVirt Jenkins 30 Jan '18

30 Jan '18

A system test invoked by the "dummy-master" change queue including change e74f3bb (stage-gh-stdci2) failed. However, this change seems not to be the root cause for this failure. Change 2ff79b3 (stage-gh-stdci2) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 2ff79b3 (stage-gh-stdci2) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://github.com/oVirt/stage-gh-stdci2/commit/e74f3bbc48cc8b76c599ec9c56f… For further details about the change that seems to be the root cause behind the testing failures see: https://github.com/oVirt/stage-gh-stdci2/commit/2ff79b3f37717e65ab84a11c167… For failed test results see: http://jenkins-staging.phx.ovirt.org/job/dummy-master_change-queue-tester/1…

1 0

[JIRA] (OVIRT-1866) Use PERFORMANCE_OPTIMIZED pipelines instead of MAX_SURVIVABILITY
by Daniel Belenky (oVirt JIRA) 30 Jan '18

30 Jan '18

This is a multi-part message in MIME format... ------------=_1517299177-24378-150 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1866?page=com.atlassian.jira.… ] Daniel Belenky updated OVIRT-1866: ---------------------------------- Labels: jenkins (was: ) > Use PERFORMANCE_OPTIMIZED pipelines instead of MAX_SURVIVABILITY > ---------------------------------------------------------------- > > Key: OVIRT-1866 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1866 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins Master > Reporter: Daniel Belenky > Assignee: infra > Labels: jenkins > > It seems that pipelines now have support to configure their behavior of serialization of objects, and since we know that this serialization never worked for us as we'd expect it to, maybe we should consider using PERFORMANCE_OPTIMIZED mode which will avoid serializing and maybe boost the performance. > [Link to subject in jenkincci-dev google|https://groups.google.com/forum/#!msg/jenkinsci-dev/F4zcOWLI32w/51qi…] -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077) ------------=_1517299177-24378-150 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1866?page=com.atlassian.jira.… ]</pre> <h3>Daniel Belenky updated OVIRT-1866:</h3> <pre>Labels: jenkins (was: )</pre> <blockquote><h3>Use PERFORMANCE_OPTIMIZED pipelines instead of MAX_SURVIVABILITY</h3> <pre> Key: OVIRT-1866 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1866 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Jenkins Master Reporter: Daniel Belenky Assignee: infra Labels: jenkins</pre> <p>It seems that pipelines now have support to configure their behavior of serialization of objects, and since we know that this serialization never worked for us as we'd expect it to, maybe we should consider using PERFORMANCE_OPTIMIZED mode which will avoid serializing and maybe boost the performance. [Link to subject in jenkincci-dev google|<a href="https://groups.google.com/forum/#!msg/jenkinsci-dev/F4zcOWLI32w/51qixjepCgAJ">https://groups.google.com/forum/#!msg/jenkinsci-dev/F4zcOWLI32w/51qixjepCgAJ</a>]</p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1517299177-24378-150--

1 0

[JIRA] (OVIRT-1866) Use PERFORMANCE_OPTIMIZED pipelines instead of MAX_SURVIVABILITY
by Barak Korren (oVirt JIRA) 30 Jan '18

30 Jan '18

This is a multi-part message in MIME format... ------------=_1517298659-23592-267 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1866?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1866: -------------------------------- Component/s: Jenkins Master > Use PERFORMANCE_OPTIMIZED pipelines instead of MAX_SURVIVABILITY > ---------------------------------------------------------------- > > Key: OVIRT-1866 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1866 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins Master > Reporter: Daniel Belenky > Assignee: infra > > It seems that pipelines now have support to configure their behavior of serialization of objects, and since we know that this serialization never worked for us as we'd expect it to, maybe we should consider using PERFORMANCE_OPTIMIZED mode which will avoid serializing and maybe boost the performance. > [Link to subject in jenkincci-dev google|https://groups.google.com/forum/#!msg/jenkinsci-dev/F4zcOWLI32w/51qi…] -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077) ------------=_1517298659-23592-267 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1866?page=com.atlassian.jira.… ]</pre> <h3>Barak Korren updated OVIRT-1866:</h3> <pre>Component/s: Jenkins Master</pre> <blockquote><h3>Use PERFORMANCE_OPTIMIZED pipelines instead of MAX_SURVIVABILITY</h3> <pre> Key: OVIRT-1866 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1866 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Jenkins Master Reporter: Daniel Belenky Assignee: infra</pre> <p>It seems that pipelines now have support to configure their behavior of serialization of objects, and since we know that this serialization never worked for us as we'd expect it to, maybe we should consider using PERFORMANCE_OPTIMIZED mode which will avoid serializing and maybe boost the performance. [Link to subject in jenkincci-dev google|<a href="https://groups.google.com/forum/#!msg/jenkinsci-dev/F4zcOWLI32w/51qixjepCgAJ">https://groups.google.com/forum/#!msg/jenkinsci-dev/F4zcOWLI32w/51qixjepCgAJ</a>]</p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1517298659-23592-267--

1 0

[JIRA] (OVIRT-1866) Use PERFORMANCE_OPTIMIZED pipelines instead of MAX_SURVIVABILITY
by Daniel Belenky (oVirt JIRA) 30 Jan '18

30 Jan '18

Daniel Belenky created OVIRT-1866: ------------------------------------- Summary: Use PERFORMANCE_OPTIMIZED pipelines instead of MAX_SURVIVABILITY Key: OVIRT-1866 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1866 Project: oVirt - virtualization made easy Issue Type: Improvement Reporter: Daniel Belenky Assignee: infra It seems that pipelines now have support to configure their behavior of serialization of objects, and since we know that this serialization never worked for us as we'd expect it to, maybe we should consider using PERFORMANCE_OPTIMIZED mode which will avoid serializing and maybe boost the performance. [Link to subject in jenkincci-dev google|https://groups.google.com/forum/#!msg/jenkinsci-dev/F4zcOWLI32w/51qi…] -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1866) Use PERFORMANCE_OPTIMIZED pipelines instead of MAX_SURVIVABILITY
by Daniel Belenky (oVirt JIRA) 30 Jan '18

30 Jan '18

This is a multi-part message in MIME format... ------------=_1517298465-14824-170 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1866?page=com.atlassian.jira.… ] Daniel Belenky updated OVIRT-1866: ---------------------------------- Epic Link: OVIRT-400 > Use PERFORMANCE_OPTIMIZED pipelines instead of MAX_SURVIVABILITY > ---------------------------------------------------------------- > > Key: OVIRT-1866 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1866 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Daniel Belenky > Assignee: infra > > It seems that pipelines now have support to configure their behavior of serialization of objects, and since we know that this serialization never worked for us as we'd expect it to, maybe we should consider using PERFORMANCE_OPTIMIZED mode which will avoid serializing and maybe boost the performance. > [Link to subject in jenkincci-dev google|https://groups.google.com/forum/#!msg/jenkinsci-dev/F4zcOWLI32w/51qi…] -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077) ------------=_1517298465-14824-170 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1866?page=com.atlassian.jira.… ]</pre> <h3>Daniel Belenky updated OVIRT-1866:</h3> <pre>Epic Link: OVIRT-400</pre> <blockquote><h3>Use PERFORMANCE_OPTIMIZED pipelines instead of MAX_SURVIVABILITY</h3> <pre> Key: OVIRT-1866 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1866 Project: oVirt - virtualization made easy Issue Type: Improvement Reporter: Daniel Belenky Assignee: infra</pre> <p>It seems that pipelines now have support to configure their behavior of serialization of objects, and since we know that this serialization never worked for us as we'd expect it to, maybe we should consider using PERFORMANCE_OPTIMIZED mode which will avoid serializing and maybe boost the performance. [Link to subject in jenkincci-dev google|<a href="https://groups.google.com/forum/#!msg/jenkinsci-dev/F4zcOWLI32w/51qixjepCgAJ">https://groups.google.com/forum/#!msg/jenkinsci-dev/F4zcOWLI32w/51qixjepCgAJ</a>]</p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1517298465-14824-170--

1 0

[oVirt Jenkins] ovirt-appliance_ovirt-4.2-pre_build-artifacts-el7-x86_64 - Build # 58 - Failure!
by jenkins＠jenkins.phx.ovirt.org 29 Jan '18

29 Jan '18

------=_Part_411_1014979441.1517245103403 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-appliance_ovirt-4.2-pre_build-artifacts-… Build: http://jenkins.ovirt.org/job/ovirt-appliance_ovirt-4.2-pre_build-artifacts-… Build Number: 58 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #58 [Daniel Belenky] Add ipinto(a)redhat.com to whitelist [Sandro Bonazzola] pywin32-py2.7: move to 4.2 and latest fedora [Sandro Bonazzola] python-windows: move to 4.2 and latest fedora [Sandro Bonazzola] py2exe-py2.7: move to 4.2 and latest fedora [Sandro Bonazzola] nsis-simple-service-plugin:: move to 4.2 and latest fedora [Daniel Belenky] Bound vdsm check-merged to el7 hosts only [Barak Korren] Make standard-enqueue support non-ovirt queues [Barak Korren] Allow customizing CQ mail addresses [Barak Korren] Enable customizing the server we deploy tested to [Barak Korren] Make pipeline-loader support upstream sources [Barak Korren] Made clone url for 'jenkins' customizable [Yuval Turgeman] Resolve network issues in kickstart ----------------- Failed Tests: ----------------- No tests ran. ------=_Part_411_1014979441.1517245103403--

1 1

Build failed in Jenkins: system-sync_mirrors-centos-base-el6-x86_64 #1136
by jenkins＠jenkins.phx.ovirt.org 29 Jan '18

29 Jan '18

See <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-base-el6-x86_64/113…> Changes: [Barak Korren] Made clone url for 'jenkins' customizable ------------------------------------------ Started by timer [EnvInject] - Loading node environment variables. Building remotely on mirrors.phx.ovirt.org (mirrors) in workspace <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-base-el6-x86_64/ws/> > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url http://gerrit.ovirt.org/jenkins.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 Pruning obsolete local branches Fetching upstream changes from http://gerrit.ovirt.org/jenkins.git > git --version # timeout=10 > git fetch --tags --progress http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/* --prune > git rev-parse origin/master^{commit} # timeout=10 Checking out Revision ffe020fb18b7f872bc817ba9eec0c0d5a82bc489 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f ffe020fb18b7f872bc817ba9eec0c0d5a82bc489 Commit message: "Made clone url for 'jenkins' customizable" > git rev-list b334ef0c5cfd393e9f699aad3d8c201e4df864e3 # timeout=10 [system-sync_mirrors-centos-base-el6-x86_64] $ /bin/bash -xe /tmp/jenkins7771361266593698969.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror centos-base-el6 x86_64 jenkins/data/mirrors-reposync.conf Checking if mirror needs a resync Traceback (most recent call last): File "/usr/bin/reposync", line 343, in <module> main() File "/usr/bin/reposync", line 175, in main my.doRepoSetup() File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 681, in doRepoSetup return self._getRepos(thisrepo, True) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 721, in _getRepos self._repos.doSetup(thisrepo) File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, in doSetup self.retrieveAllMD() File "/usr/lib/python2.7/site-packages/yum/repos.py", line 88, in retrieveAllMD dl = repo._async and repo._commonLoadRepoXML(repo) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1465, in _commonLoadRepoXML local = self.cachedir + '/repomd.xml' File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 774, in <lambda> cachedir = property(lambda self: self._dirGetAttr('cachedir')) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 757, in _dirGetAttr self.dirSetup() File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 735, in dirSetup self._dirSetupMkdir_p(dir) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 712, in _dirSetupMkdir_p raise Errors.RepoError, msg yum.Errors.RepoError: Error making cache directory: /home/jenkins/mirrors_cache/fedora-updates-fc24/gen error was: [Errno 17] File exists: '/home/jenkins/mirrors_cache/fedora-updates-fc24/gen' Build step 'Execute shell' marked build as failure

1 1

Build failed in Jenkins: system-sync_mirrors-fedora-updates-fc24-x86_64 #1052
by jenkins＠jenkins.phx.ovirt.org 29 Jan '18

29 Jan '18

See <http://jenkins.ovirt.org/job/system-sync_mirrors-fedora-updates-fc24-x86_64…> Changes: [Barak Korren] Made clone url for 'jenkins' customizable ------------------------------------------ Started by timer [EnvInject] - Loading node environment variables. Building remotely on mirrors.phx.ovirt.org (mirrors) in workspace <http://jenkins.ovirt.org/job/system-sync_mirrors-fedora-updates-fc24-x86_64…> > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url http://gerrit.ovirt.org/jenkins.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 Pruning obsolete local branches Fetching upstream changes from http://gerrit.ovirt.org/jenkins.git > git --version # timeout=10 > git fetch --tags --progress http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/* --prune > git rev-parse origin/master^{commit} # timeout=10 Checking out Revision ffe020fb18b7f872bc817ba9eec0c0d5a82bc489 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f ffe020fb18b7f872bc817ba9eec0c0d5a82bc489 Commit message: "Made clone url for 'jenkins' customizable" > git rev-list b334ef0c5cfd393e9f699aad3d8c201e4df864e3 # timeout=10 [system-sync_mirrors-fedora-updates-fc24-x86_64] $ /bin/bash -xe /tmp/jenkins180117895611239583.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror fedora-updates-fc24 x86_64 jenkins/data/mirrors-reposync.conf Checking if mirror needs a resync Traceback (most recent call last): File "/usr/bin/reposync", line 343, in <module> main() File "/usr/bin/reposync", line 175, in main my.doRepoSetup() File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 681, in doRepoSetup return self._getRepos(thisrepo, True) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 721, in _getRepos self._repos.doSetup(thisrepo) File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, in doSetup self.retrieveAllMD() File "/usr/lib/python2.7/site-packages/yum/repos.py", line 112, in retrieveAllMD repo._revertOldRepoXML() File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1331, in _revertOldRepoXML os.rename(old_data['old_local'], old_data['local']) OSError: [Errno 2] No such file or directory Build step 'Execute shell' marked build as failure

1 1

PHX planned maintenance 29.01.2018 @19:00 GMT
by Evgheni Dereveanchin 29 Jan '18

29 Jan '18

Hi everyone, Planned works are going to be performed in the PHX data center today. They are related to core networking hardware upgrades and may cause short connectivity loss to services hosted by the oVirt project, including: * Jenkins CI * Package repositories * project website * mailing lists The maintenance window starts at 19:00 GMT and has a duration of one hour. I will pause CI job execution before the maintenance window so builds will be queued and executed after network upgrades are implemented to decrease the possibility of false positives. I will follow up with any further updates. -- Regards, Evgheni Dereveanchin

1 1

[CQ]: 86868, 5 (otopi) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 29 Jan '18

29 Jan '18

A system test invoked by the "ovirt-master" change queue including change 86868,5 (otopi) failed. However, this change seems not to be the root cause for this failure. Change 86679,4 (otopi) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86679,4 (otopi) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86868/5 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86679/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5155/

1 0

[CQ]: 86869, 1 (otopi) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 29 Jan '18

29 Jan '18

A system test invoked by the "ovirt-master" change queue including change 86869,1 (otopi) failed. However, this change seems not to be the root cause for this failure. Change 86679,4 (otopi) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86679,4 (otopi) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86869/1 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86679/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5154/

1 0

[CQ]: 86865, 8 (otopi) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 29 Jan '18

29 Jan '18

A system test invoked by the "ovirt-master" change queue including change 86865,8 (otopi) failed. However, this change seems not to be the root cause for this failure. Change 86679,4 (otopi) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86679,4 (otopi) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86865/8 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86679/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5149/

2 1

[CQ]: 86679,4 (otopi) failed "ovirt-master" system tests
by oVirt Jenkins 29 Jan '18

29 Jan '18

Change 86679,4 (otopi) is probably the reason behind recent system test failures in the "ovirt-master" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/86679/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5145/

1 0

[oVirt Jenkins] ovirt-system-tests_performance-suite-master - Build # 76 - Failure!
by jenkins＠jenkins.phx.ovirt.org 29 Jan '18

29 Jan '18

------=_Part_361_1148288594.1516964554521 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-system-tests_performance-suite-master/ Build: http://jenkins.ovirt.org/job/ovirt-system-tests_performance-suite-master/76/ Build Number: 76 Build Status: Failure Triggered By: Started by timer, Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #76 [Gal Ben Haim] 4.1: Update reposync config [Daniel Belenky] dsl test_api: remove unneeded print [Sandro Bonazzola] vcredist-x86: move to 4.2 and latest fedora ----------------- Failed Tests: ----------------- 1 tests failed. FAILED: 040_add_hosts_vms.add_cluster Error Message: Fault reason is "Operation Failed". Fault detail is "[Cannot create Cluster. The chosen CPU is not supported.]". HTTP response code is 400. Stack Trace: Traceback (most recent call last): File "/usr/lib64/python2.7/unittest/case.py", line 369, in run testMethod() File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 129, in wrapped_test test() File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 59, in wrapper return func(get_test_prefix(), *args, **kwargs) File "/home/jenkins/workspace/ovirt-system-tests_performance-suite-master/ovirt-system-tests/performance-suite-master/test-scenarios/040_add_hosts_vms.py", line 231, in add_cluster ballooning_enabled=True, File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py", line 4766, in add return self._internal_add(cluster, headers, query, wait) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 232, in _internal_add return future.wait() if wait else future File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 55, in wait return self._code(response) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 229, in callback self._check_fault(response) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 132, in _check_fault self._raise_error(response, body) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 118, in _raise_error raise error Error: Fault reason is "Operation Failed". Fault detail is "[Cannot create Cluster. The chosen CPU is not supported.]". HTTP response code is 400. ------=_Part_361_1148288594.1516964554521--

1 6

[oVirt Jenkins] ovirt-system-tests_he-basic-ansible-suite-master - Build # 14 - Failure!
by jenkins＠jenkins.phx.ovirt.org 29 Jan '18

29 Jan '18

------=_Part_289_1271942520.1516761492809 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-ansible-suite-mast… Build: http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-ansible-suite-mast… Build Number: 14 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #14 [Your Name] networking: pass argument to exec_func_args instead of lambda ----------------- Failed Tests: ----------------- No tests ran. ------=_Part_289_1271942520.1516761492809--

1 5

Build failed in Jenkins: system-sync_mirrors-centos-updates-el7-x86_64 #1219
by jenkins＠jenkins.phx.ovirt.org 29 Jan '18

29 Jan '18

See <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-updates-el7-x86_64/…> ------------------------------------------ Started by timer [EnvInject] - Loading node environment variables. Building remotely on mirrors.phx.ovirt.org (mirrors) in workspace <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-updates-el7-x86_64/…> > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url http://gerrit.ovirt.org/jenkins.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 Pruning obsolete local branches Fetching upstream changes from http://gerrit.ovirt.org/jenkins.git > git --version # timeout=10 > git fetch --tags --progress http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/* --prune > git rev-parse origin/master^{commit} # timeout=10 Checking out Revision 5dc484c857f541fc5d315ac31dd83bfba6812636 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 5dc484c857f541fc5d315ac31dd83bfba6812636 Commit message: "Bound vdsm check-merged to el7 hosts only" > git rev-list 5dc484c857f541fc5d315ac31dd83bfba6812636 # timeout=10 [system-sync_mirrors-centos-updates-el7-x86_64] $ /bin/bash -xe /tmp/jenkins3305241652956965076.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror centos-updates-el7 x86_64 jenkins/data/mirrors-reposync.conf Checking if mirror needs a resync Traceback (most recent call last): File "/usr/bin/reposync", line 343, in <module> main() File "/usr/bin/reposync", line 175, in main my.doRepoSetup() File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 681, in doRepoSetup return self._getRepos(thisrepo, True) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 721, in _getRepos self._repos.doSetup(thisrepo) File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, in doSetup self.retrieveAllMD() File "/usr/lib/python2.7/site-packages/yum/repos.py", line 88, in retrieveAllMD dl = repo._async and repo._commonLoadRepoXML(repo) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1465, in _commonLoadRepoXML local = self.cachedir + '/repomd.xml' File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 774, in <lambda> cachedir = property(lambda self: self._dirGetAttr('cachedir')) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 757, in _dirGetAttr self.dirSetup() File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 735, in dirSetup self._dirSetupMkdir_p(dir) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 712, in _dirSetupMkdir_p raise Errors.RepoError, msg yum.Errors.RepoError: Error making cache directory: /home/jenkins/mirrors_cache/centos-updates-el7 error was: [Errno 17] File exists: '/home/jenkins/mirrors_cache/centos-updates-el7' Build step 'Execute shell' marked build as failure

1 1

[CQ]: 86849, 2 (ovirt-engine-dashboard) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 28 Jan '18

28 Jan '18

A system test invoked by the "ovirt-4.2" change queue including change 86849,2 (ovirt-engine-dashboard) failed. However, this change seems not to be the root cause for this failure. Change 86582,1 (ovirt-engine-dashboard) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86582,1 (ovirt-engine- dashboard) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86849/2 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86582/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/368/

1 0

[JIRA] (OVIRT-1865) Add me to Jenkins whitelist
by Daniel Belenky (oVirt JIRA) 28 Jan '18

28 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1865?page=com.atlassian.jira.… ] Daniel Belenky updated OVIRT-1865: ---------------------------------- Assignee: Daniel Belenky (was: infra) Status: In Progress (was: To Do) > Add me to Jenkins whitelist > ---------------------------- > > Key: OVIRT-1865 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1865 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Israel Pinto > Assignee: Daniel Belenky > > Please add me to Jenkins whitelist, > See patch: https://gerrit.ovirt.org/#/c/86832/ failed to run automate verification -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[CQ]: 86849, 2 (ovirt-engine-dashboard) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 28 Jan '18

28 Jan '18

A system test invoked by the "ovirt-4.2" change queue including change 86849,2 (ovirt-engine-dashboard) failed. However, this change seems not to be the root cause for this failure. Change 86582,1 (ovirt-engine-dashboard) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86582,1 (ovirt-engine- dashboard) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86849/2 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86582/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/367/

1 0

[JIRA] (OVIRT-1865) Add me to Jenkins whitelist
by Israel Pinto (oVirt JIRA) 28 Jan '18

28 Jan '18

This is a multi-part message in MIME format... ------------=_1517144648-32100-186 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Israel Pinto created OVIRT-1865: ----------------------------------- Summary: Add me to Jenkins whitelist Key: OVIRT-1865 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1865 Project: oVirt - virtualization made easy Issue Type: Task Reporter: Israel Pinto Assignee: infra Please add me to Jenkins whitelist, See patch: https://gerrit.ovirt.org/#/c/86832/ failed to run automate verification -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077) ------------=_1517144648-32100-186 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <h3>Israel Pinto created OVIRT-1865:</h3> <pre> Summary: Add me to Jenkins whitelist Key: OVIRT-1865 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1865 Project: oVirt - virtualization made easy Issue Type: Task Reporter: Israel Pinto Assignee: infra</pre> <p>Please add me to Jenkins whitelist,</p> <p>See patch: <a href="https://gerrit.ovirt.org/#/c/86832/">https://gerrit.ovirt.org/#/c/86832/</a> failed to run automate verification</p> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1517144648-32100-186--

1 0

[CQ]: 86848, 1 (ovirt-engine-dashboard) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 28 Jan '18

28 Jan '18

A system test invoked by the "ovirt-4.2" change queue including change 86848,1 (ovirt-engine-dashboard) failed. However, this change seems not to be the root cause for this failure. Change 86582,1 (ovirt-engine-dashboard) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86582,1 (ovirt-engine- dashboard) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86848/1 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86582/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/366/

1 0

[JIRA] (OVIRT-1864) investigate why vdsm check-merged job fails on non el7 hosts
by Daniel Belenky (oVirt JIRA) 28 Jan '18

28 Jan '18

This is a multi-part message in MIME format... ------------=_1517125000-26985-214 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Daniel Belenky created OVIRT-1864: ------------------------------------- Summary: investigate why vdsm check-merged job fails on non el7 hosts Key: OVIRT-1864 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1864 Project: oVirt - virtualization made easy Issue Type: Bug Reporter: Daniel Belenky Assignee: infra It seems that vdsm check-merged job fails on non el7 hosts. It just times out. Maybe el7 hosts are faster(?) For now, [https://gerrit.ovirt.org/#/c/86780/|https://gerrit.ovirt.org/#/c/86780/] bounds vdsm check-merged to run on el7 hosts only. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077) ------------=_1517125000-26985-214 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <h3>Daniel Belenky created OVIRT-1864:</h3> <pre> Summary: investigate why vdsm check-merged job fails on non el7 hosts Key: OVIRT-1864 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1864 Project: oVirt - virtualization made easy Issue Type: Bug Reporter: Daniel Belenky Assignee: infra</pre> <p>It seems that vdsm check-merged job fails on non el7 hosts. It just times out. Maybe el7 hosts are faster(?) For now, [<a href="https://gerrit.ovirt.org/#/c/86780/">https://gerrit.ovirt.org/#/c/86780/</a>|<a href="https://gerrit.ovirt.org/#/c/86780/">https://gerrit.ovirt.org/#/c/86780/</a>] bounds vdsm check-merged to run on el7 hosts only.</p> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1517125000-26985-214--

1 0

[JIRA] (OVIRT-1864) investigate why vdsm check-merged job fails on non el7 hosts
by Daniel Belenky (oVirt JIRA) 28 Jan '18

28 Jan '18

This is a multi-part message in MIME format... ------------=_1517125000-29652-120 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1864?page=com.atlassian.jira.… ] Daniel Belenky updated OVIRT-1864: ---------------------------------- Epic Link: OVIRT-400 > investigate why vdsm check-merged job fails on non el7 hosts > ------------------------------------------------------------ > > Key: OVIRT-1864 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1864 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Daniel Belenky > Assignee: infra > > It seems that vdsm check-merged job fails on non el7 hosts. It just times out. > Maybe el7 hosts are faster(?) > For now, [https://gerrit.ovirt.org/#/c/86780/|https://gerrit.ovirt.org/#/c/86780/] bounds vdsm check-merged to run on el7 hosts only. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077) ------------=_1517125000-29652-120 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1864?page=com.atlassian.jira.… ]</pre> <h3>Daniel Belenky updated OVIRT-1864:</h3> <pre>Epic Link: OVIRT-400</pre> <blockquote><h3>investigate why vdsm check-merged job fails on non el7 hosts</h3> <pre> Key: OVIRT-1864 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1864 Project: oVirt - virtualization made easy Issue Type: Bug Reporter: Daniel Belenky Assignee: infra</pre> <p>It seems that vdsm check-merged job fails on non el7 hosts. It just times out. Maybe el7 hosts are faster(?) For now, [<a href="https://gerrit.ovirt.org/#/c/86780/">https://gerrit.ovirt.org/#/c/86780/</a>|<a href="https://gerrit.ovirt.org/#/c/86780/">https://gerrit.ovirt.org/#/c/86780/</a>] bounds vdsm check-merged to run on el7 hosts only.</p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1517125000-29652-120--

1 0

Build failed in Jenkins: system-sync_mirrors-epel-el6-x86_64 #1143
by jenkins＠jenkins.phx.ovirt.org 28 Jan '18

28 Jan '18

See <http://jenkins.ovirt.org/job/system-sync_mirrors-epel-el6-x86_64/1143/displ…> ------------------------------------------ Started by timer [EnvInject] - Loading node environment variables. Building remotely on mirrors.phx.ovirt.org (mirrors) in workspace <http://jenkins.ovirt.org/job/system-sync_mirrors-epel-el6-x86_64/ws/> > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url http://gerrit.ovirt.org/jenkins.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 Pruning obsolete local branches Fetching upstream changes from http://gerrit.ovirt.org/jenkins.git > git --version # timeout=10 > git fetch --tags --progress http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/* --prune > git rev-parse origin/master^{commit} # timeout=10 Checking out Revision 304b66c2aca3fa56530cd337e97f5fe84ec44cf0 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 304b66c2aca3fa56530cd337e97f5fe84ec44cf0 Commit message: "nsis-simple-service-plugin:: move to 4.2 and latest fedora" > git rev-list 304b66c2aca3fa56530cd337e97f5fe84ec44cf0 # timeout=10 [system-sync_mirrors-epel-el6-x86_64] $ /bin/bash -xe /tmp/jenkins8369699459956369535.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror epel-el6 x86_64 jenkins/data/mirrors-reposync.conf Checking if mirror needs a resync Traceback (most recent call last): File "/usr/bin/reposync", line 343, in <module> main() File "/usr/bin/reposync", line 175, in main my.doRepoSetup() File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 681, in doRepoSetup return self._getRepos(thisrepo, True) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 721, in _getRepos self._repos.doSetup(thisrepo) File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, in doSetup self.retrieveAllMD() File "/usr/lib/python2.7/site-packages/yum/repos.py", line 88, in retrieveAllMD dl = repo._async and repo._commonLoadRepoXML(repo) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1474, in _commonLoadRepoXML if self._latestRepoXML(local): File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1443, in _latestRepoXML oxml = self._saveOldRepoXML(local) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1300, in _saveOldRepoXML shutil.copy2(local, old_local) File "/usr/lib64/python2.7/shutil.py", line 131, in copy2 copystat(src, dst) File "/usr/lib64/python2.7/shutil.py", line 98, in copystat os.utime(dst, (st.st_atime, st.st_mtime)) OSError: [Errno 2] No such file or directory: '/home/jenkins/mirrors_cache/fedora-updates-fc26/repomd.xml.old.tmp' Build step 'Execute shell' marked build as failure

1 1

[oVirt Jenkins] ovirt-appliance_master_build-artifacts-el7-x86_64 - Build # 683 - Failure!
by jenkins＠jenkins.phx.ovirt.org 27 Jan '18

27 Jan '18

------=_Part_307_1653395375.1516801460194 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-appliance_master_build-artifacts-el7-x86… Build: http://jenkins.ovirt.org/job/ovirt-appliance_master_build-artifacts-el7-x86… Build Number: 683 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #683 [Sandro Bonazzola] automation: check and save unsigned rpms ----------------- Failed Tests: ----------------- No tests ran. ------=_Part_307_1653395375.1516801460194--

1 4

[CQ]: 86391, 4 (ovirt-provider-ovn) failed "ovirt-master" system tests
by oVirt Jenkins 27 Jan '18

27 Jan '18

Change 86391,4 (ovirt-provider-ovn) is probably the reason behind recent system test failures in the "ovirt-master" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/86391/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5132/

1 0

[CQ]: 82386, 1 (nsis-simple-service-plugin) failed "ovirt-4.1" system tests
by oVirt Jenkins 26 Jan '18

26 Jan '18

Change 82386,1 (nsis-simple-service-plugin) is probably the reason behind recent system test failures in the "ovirt-4.1" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/82386/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1544/

1 0

[JIRA] (OVIRT-1863) Service Alert: foreman/HTTP tcp connection going up and down
by Evgheni Dereveanchin (oVirt JIRA) 26 Jan '18

26 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1863?page=com.atlassian.jira.… ] Evgheni Dereveanchin reassigned OVIRT-1863: ------------------------------------------- Assignee: Evgheni Dereveanchin (was: infra) > Service Alert: foreman/HTTP tcp connection going up and down > ------------------------------------------------------------ > > Key: OVIRT-1863 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1863 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Dafna Ron > Assignee: Evgheni Dereveanchin > > Hi, > we have been getting service disruption alerts for foreman http > The service is going up/down. > Can you please investigate this when you get a chance? > ***** Icinga ***** > Notification Type: PROBLEM > Service: HTTP tcp connection > Host: foreman > Address: 66.187.230.32 > State: CRITICAL > Date/Time: Fri Jan 26 08:42:38 UTC 2018 > ***** Icinga ***** > Notification Type: RECOVERY > Service: HTTP tcp connection > Host: foreman > Address: 66.187.230.32 > State: OK > Date/Time: Fri Jan 26 14:45:38 UTC 2018 > Additional Info: > HTTP OK: HTTP/1.1 200 OK - 4131 bytes in 1.563 second response time -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[CQ]: 82234,1 (vcredist-x86) failed "ovirt-4.2" system tests
by oVirt Jenkins 26 Jan '18

26 Jan '18

Change 82234,1 (vcredist-x86) is probably the reason behind recent system test failures in the "ovirt-4.2" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/82234/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/363/

1 0

[ OST Failure Report ] [ oVirt Master (vcredist-x86) ] [ 26-01-2018 ] [ 002_bootstrap.verify_add_all_hosts ]
by Dafna Ron 26 Jan '18

26 Jan '18

Hi, We had a failure on test 002_bootstrap.verify_add_all_hosts in Ovirt Master I don't think the patch reported is related to the issue. >From what I can see, the host was locked when we tried to query its status and since we couldn't fence the host we exited in timeout. I do not think the reported patch was the reason for failure. *Link and headline of reported patches: https://gerrit.ovirt.org/#/c/82234/1 <https://gerrit.ovirt.org/#/c/82234/1> - Initial import from ovirt-wgt-toolchainLink to Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5123/ <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5123/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5123/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5123/artifact/>(Relevant) error snippet from the log: <error>2018-01-26 06:37:31,022-05 INFO [org.ovirt.engine.core.bll.RefreshHostCapabilitiesCommand] (ForkJoinPool-1-worker-4) [75b3e642] Failed to Acquire Lock to object 'EngineLock:{exclusiveLocks='[52ee1a61-31c3-4af8-ae28-65f0953f1804=VDS, HOST_NETWORK52ee1a61-31c3-4af8-ae28-65f0953f1804=HOST_NETWORK]', sharedLocks=''}'2018-01-26 06:37:31,022-05 WARN [org.ovirt.engine.core.bll.RefreshHostCapabilitiesCommand] (ForkJoinPool-1-worker-4) [75b3e642] Validation of action 'RefreshHostCapabilities' failed for user SYSTEM. Reasons: VAR__ACTION__REFRESH,VAR__TYPE__HOST_CAPABILITIES,ACTION_TYPE_FAILED_OBJECT_LOCKED2018-01-26 06:37:31,373-05 DEBUG [org.ovirt.vdsm.jsonrpc.client.reactors.stomp.impl.Message] (SSL Stomp Reactor) [1d883766] MESSAGEcontent-length:80destination:jms.topic.vdsm_responsescontent-type:application/jsonsubscription:ce434ca4-0c91-44b6-843a-7f8cff40d8e4{"jsonrpc": "2.0", "id": "8f1c8652-044c-4051-85d7-3d290ee2014f", "result": true}^@2018-01-26 06:37:31,374-05 DEBUG [org.ovirt.vdsm.jsonrpc.client.internal.ResponseWorker] (ResponseWorker) [] Message received: {"jsonrpc": "2.0", "id": "8f1c8652-044c-4051-85d7-3d290ee2014f", "result": true}2018-01-26 06:37:31,374-05 ERROR [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for "8f1c8652-044c-4051-85d7-3d290ee2014f"2018-01-26 06:37:31,376-05 DEBUG [org.ovirt.vdsm.jsonrpc.client.reactors.stomp.impl.Message] (SSL Stomp Reactor) [1d883766] MESSAGEcontent-length:802018-01-26 06:37:35,147-05 ERROR [org.ovirt.engine.core.bll.pm.FenceProxyLocator] (EE-ManagedThreadFactory-engineScheduled-Thread-8) [78ab5d20] Can not run fence action on host 'lago-basic-suite-master-host-0', no suitable proxy host was found.</error>*

1 0

[JIRA] (OVIRT-1863) Service Alert: foreman/HTTP tcp connection going up and down
by Dafna Ron (oVirt JIRA) 26 Jan '18

26 Jan '18

Dafna Ron created OVIRT-1863: -------------------------------- Summary: Service Alert: foreman/HTTP tcp connection going up and down Key: OVIRT-1863 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1863 Project: oVirt - virtualization made easy Issue Type: Task Reporter: Dafna Ron Assignee: infra Hi, we have been getting service disruption alerts for foreman http The service is going up/down. Can you please investigate this when you get a chance? ***** Icinga ***** Notification Type: PROBLEM Service: HTTP tcp connection Host: foreman Address: 66.187.230.32 State: CRITICAL Date/Time: Fri Jan 26 08:42:38 UTC 2018 ***** Icinga ***** Notification Type: RECOVERY Service: HTTP tcp connection Host: foreman Address: 66.187.230.32 State: OK Date/Time: Fri Jan 26 14:45:38 UTC 2018 Additional Info: HTTP OK: HTTP/1.1 200 OK - 4131 bytes in 1.563 second response time -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[CQ]: 82386, 1 (nsis-simple-service-plugin) failed "ovirt-4.2" system tests
by oVirt Jenkins 26 Jan '18

26 Jan '18

Change 82386,1 (nsis-simple-service-plugin) is probably the reason behind recent system test failures in the "ovirt-4.2" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/82386/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/361/

1 0

[CQ]: 80073, 2 (ovirt-js-dependencies) failed "ovirt-4.2" system tests
by oVirt Jenkins 26 Jan '18

26 Jan '18

Change 80073,2 (ovirt-js-dependencies) is probably the reason behind recent system test failures in the "ovirt-4.2" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/80073/2 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/360/

1 0

[CQ]: 82632,1 (py2exe-py2.7) failed "ovirt-4.2" system tests
by oVirt Jenkins 26 Jan '18

26 Jan '18

Change 82632,1 (py2exe-py2.7) is probably the reason behind recent system test failures in the "ovirt-4.2" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/82632/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/358/

1 0

[CQ]: 82638,1 (python-windows) failed "ovirt-4.2" system tests
by oVirt Jenkins 26 Jan '18

26 Jan '18

Change 82638,1 (python-windows) is probably the reason behind recent system test failures in the "ovirt-4.2" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/82638/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/357/

1 0

[CQ]: 82234,1 (vcredist-x86) failed "ovirt-master" system tests
by oVirt Jenkins 26 Jan '18

26 Jan '18

Change 82234,1 (vcredist-x86) is probably the reason behind recent system test failures in the "ovirt-master" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/82234/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5123/

1 0

[CQ]: 82667,1 (pywin32-py2.7) failed "ovirt-4.2" system tests
by oVirt Jenkins 26 Jan '18

26 Jan '18

Change 82667,1 (pywin32-py2.7) is probably the reason behind recent system test failures in the "ovirt-4.2" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/82667/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/355/

1 0

[CQ]: 82234,1 (vcredist-x86) failed "ovirt-4.2" system tests
by oVirt Jenkins 26 Jan '18

26 Jan '18

Change 82234,1 (vcredist-x86) is probably the reason behind recent system test failures in the "ovirt-4.2" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/82234/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/353/

1 0

[CQ]: 86819, 2 (cockpit-ovirt) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 26 Jan '18

26 Jan '18

A system test invoked by the "ovirt-4.2" change queue including change 86819,2 (cockpit-ovirt) failed. However, this change seems not to be the root cause for this failure. Change 86648,1 (cockpit-ovirt) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86648,1 (cockpit-ovirt) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86819/2 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86648/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/351/

1 0

[CQ]: 86820, 1 (cockpit-ovirt) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 26 Jan '18

26 Jan '18

A system test invoked by the "ovirt-4.2" change queue including change 86820,1 (cockpit-ovirt) failed. However, this change seems not to be the root cause for this failure. Change 86648,1 (cockpit-ovirt) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86648,1 (cockpit-ovirt) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86820/1 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86648/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/350/

1 0

[CQ]: 86818, 1 (cockpit-ovirt) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 26 Jan '18

26 Jan '18

A system test invoked by the "ovirt-4.2" change queue including change 86818,1 (cockpit-ovirt) failed. However, this change seems not to be the root cause for this failure. Change 86648,1 (cockpit-ovirt) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86648,1 (cockpit-ovirt) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86818/1 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86648/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/348/

1 0

[CQ]: 86811, 1 (imgbased) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 26 Jan '18

26 Jan '18

A system test invoked by the "ovirt-4.2" change queue including change 86811,1 (imgbased) failed. However, this change seems not to be the root cause for this failure. Change 86773,1 (imgbased) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86773,1 (imgbased) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86811/1 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86773/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/346/

1 0

[CQ]: 86810, 1 (imgbased) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 26 Jan '18

26 Jan '18

A system test invoked by the "ovirt-4.2" change queue including change 86810,1 (imgbased) failed. However, this change seems not to be the root cause for this failure. Change 86773,1 (imgbased) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86773,1 (imgbased) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86810/1 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86773/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/345/

1 0

[CQ]: 86734,1 (ovirt-engine) failed "ovirt-4.1" system tests
by oVirt Jenkins 25 Jan '18

25 Jan '18

Change 86734,1 (ovirt-engine) is probably the reason behind recent system test failures in the "ovirt-4.1" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/86734/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1538/

1 0

[oVirt Jenkins] ovirt-appliance_ovirt-4.2_build-artifacts-el7-x86_64 - Build # 23 - Failure!
by jenkins＠jenkins.phx.ovirt.org 25 Jan '18

25 Jan '18

------=_Part_263_1084542245.1516709967862 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Project: http://jenkins.ovirt.org/job/ovirt-appliance_ovirt-4.2_build-artifacts-el7-… Build: http://jenkins.ovirt.org/job/ovirt-appliance_ovirt-4.2_build-artifacts-el7-… Build Number: 23 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #23 [Gal Ben Haim] ost: Add 4.2 to the manual job [Gal Ben Haim] ost: Adding 'he-basic-ansible' to the manual job [Daniel Belenky] Add line brak before mock_enable_network [Gal Ben Haim] ost: Fix Lago custom repo [Greg Sheremeta] ovirt-js-dependencies: add jobs for fc27, add 4.2 branch [Nir Soffer] ioprocess: Remove Fedora 26 builds [Yuval Turgeman] image-ng: move chroot distro to el7 [Sandro Bonazzola] ovirt-engine: add 3.6-els branch [Sandro Bonazzola] build: switch to ovirt-release42 ----------------- Failed Tests: ----------------- No tests ran. ------=_Part_263_1084542245.1516709967862--

1 1

[JIRA] (OVIRT-1862) vm0002.workers-phx.ovirt.org malfunction
by Daniel Belenky (oVirt JIRA) 25 Jan '18

25 Jan '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1862?page=com.atlassian.jira.… ] Daniel Belenky reassigned OVIRT-1862: ------------------------------------- Assignee: Evgheni Dereveanchin (was: infra) > vm0002.workers-phx.ovirt.org malfunction > ---------------------------------------- > > Key: OVIRT-1862 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1862 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Daniel Belenky > Assignee: Evgheni Dereveanchin > > Hey, > It seems that something bad is happening on vm0002.workers-phx.ovirt.org. Jobs fail with AccessDeniedException on this slave. > Can you please check what happened? > We've put the slave offline for now. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1862) vm0002.workers-phx.ovirt.org malfunction
by Daniel Belenky (oVirt JIRA) 25 Jan '18

25 Jan '18

Daniel Belenky created OVIRT-1862: ------------------------------------- Summary: vm0002.workers-phx.ovirt.org malfunction Key: OVIRT-1862 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1862 Project: oVirt - virtualization made easy Issue Type: Bug Reporter: Daniel Belenky Assignee: infra Hey, It seems that something bad is happening on vm0002.workers-phx.ovirt.org. Jobs fail with AccessDeniedException on this slave. Can you please check what happened? We've put the slave offline for now. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[JIRA] (OVIRT-1861) Re: [ovirt-users] [ANN] oVirt 4.1.9 Release is now available
by sbonazzo (oVirt JIRA) 25 Jan '18

25 Jan '18

sbonazzo created OVIRT-1861: ------------------------------- Summary: Re: [ovirt-users] [ANN] oVirt 4.1.9 Release is now available Key: OVIRT-1861 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1861 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: sbonazzo Assignee: infra 2018-01-24 13:47 GMT+01:00 Arman Khalatyan <arm2arm(a)gmail.com>: > Thanks for the announcement. > A little comment: could you please fix the line yum install > <http://resources.ovirt.org/pub/yum-repo/ovirt-release41.rpm > <http://resources.ovirt.org/pub/yum-repo/ovirt-release41.rpm%3E> > There is an extra '<' symbol there since 4.0.x :=) > > Thanks for the feedback, I opened https://github.com/oVirt/ovirt-site/issues/1503 to track this. Opening a ticket on infra as well for further investigations. > > On Wed, Jan 24, 2018 at 12:00 PM, Lev Veyde <lveyde(a)redhat.com> wrote: > >> The oVirt Project is pleased to announce the availability of the oVirt >> 4.1.9 release, as of January 24th, 2017 >> >> This update is the ninth in a series of stabilization updates to the 4.1 >> series. >> >> Please note that no further updates will be issued for the 4.1 series. >> We encourage users to upgrade to 4.2 series to receive new features and >> updates. >> >> This release is available now for: >> * Red Hat Enterprise Linux 7.4 or later >> * CentOS Linux (or similar) 7.4 or later >> >> This release supports Hypervisor Hosts running: >> * Red Hat Enterprise Linux 7.4 or later >> * CentOS Linux (or similar) 7.4 or later >> * oVirt Node 4.1 >> >> See the release notes [1] for installation / upgrade instructions and >> a list of new features and bugs fixed. >> >> Notes: >> - oVirt Appliance is already available >> - oVirt Live is already available [2] >> - oVirt Node will be available soon [2] >> >> Additional Resources: >> * Read more about the oVirt 4.1.9 release highlights:http://www.ovirt.or >> g/release/4.1.9/ >> * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt >> * Check out the latest project news on the oVirt blog: >> http://www.ovirt.org/blog/ >> >> [1] http://www.ovirt.org/release/4.1.9/ >> [2] http://resources.ovirt.org/pub/ovirt-4.1/iso/ >> >> -- >> >> Lev Veyde >> >> Software Engineer, RHCE | RHCVA | MCITP >> >> Red Hat Israel >> >> <https://www.redhat.com> >> >> lev(a)redhat.com | lveyde(a)redhat.com >> <https://red.ht/sig> >> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> >> > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > > -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

[CQ]: 86757, 1 (ovirt-engine-api-model) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 25 Jan '18

25 Jan '18

A system test invoked by the "ovirt-4.2" change queue including change 86757,1 (ovirt-engine-api-model) failed. However, this change seems not to be the root cause for this failure. Change 86692,1 (ovirt-engine-api-model) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86692,1 (ovirt-engine-api- model) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86757/1 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86692/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/331/

2 1

[CQ]: 86639, 7 (vdsm) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 25 Jan '18

25 Jan '18

A system test invoked by the "ovirt-master" change queue including change 86639,7 (vdsm) failed. However, this change seems not to be the root cause for this failure. Change 86474,33 (vdsm) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86474,33 (vdsm) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86639/7 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86474/33 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5108/

1 0

[CQ]: 86716, 2 (vdsm) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 25 Jan '18

25 Jan '18

A system test invoked by the "ovirt-master" change queue including change 86716,2 (vdsm) failed. However, this change seems not to be the root cause for this failure. Change 86474,33 (vdsm) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86474,33 (vdsm) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86716/2 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86474/33 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5105/

1 0