- Infra - oVirt List Archives

[JENKINS] Failed to setup proejct standard-manual-runner-gal
by jenkins＠jenkins.phx.ovirt.org 24 Dec '18

24 Dec '18

Failed to run project_setup.sh for: #30 kubevirt [check-patch]. It probably means that docker_cleanup.py failed. This step doesn't fail the job, but we do collect data about such failures to find the root cause. Infra owner, ensure that we're not running out of disk space on openshift-guaranteed-qos-m9gbb.

1 0

[JENKINS] Failed to setup proejct standard-manual-runner-gal
by jenkins＠jenkins.phx.ovirt.org 24 Dec '18

24 Dec '18

Failed to run project_setup.sh for: #30 kubevirt [check-patch]. It probably means that docker_cleanup.py failed. This step doesn't fail the job, but we do collect data about such failures to find the root cause. Infra owner, ensure that we're not running out of disk space on openshift-guaranteed-qos-zl946.

1 0

[JENKINS] Failed to setup proejct standard-manual-runner-gal
by jenkins＠jenkins.phx.ovirt.org 24 Dec '18

24 Dec '18

Failed to run project_setup.sh for: #30 kubevirt [check-patch]. It probably means that docker_cleanup.py failed. This step doesn't fail the job, but we do collect data about such failures to find the root cause. Infra owner, ensure that we're not running out of disk space on openshift-guaranteed-qos-mmfl0.

1 0

[JENKINS] Failed to setup proejct standard-manual-runner-gal
by jenkins＠jenkins.phx.ovirt.org 24 Dec '18

24 Dec '18

Failed to run project_setup.sh for: #30 kubevirt [check-patch]. It probably means that docker_cleanup.py failed. This step doesn't fail the job, but we do collect data about such failures to find the root cause. Infra owner, ensure that we're not running out of disk space on openshift-guaranteed-qos-v3qnb.

1 0

[oVirt Jenkins] ovirt-appliance_master_build-artifacts-el7-x86_64 - Build # 1019 - Failure!
by jenkins＠jenkins.phx.ovirt.org 24 Dec '18

24 Dec '18

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: 1019 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #1019 [Yuval Turgeman] build: change root fs to be a logical volume ----------------- Failed Tests: ----------------- No tests ran.

1 1

Build failed in Jenkins: system-sync_mirrors-centos-kvm-common-el7-x86_64 #2035
by jenkins＠jenkins.phx.ovirt.org 24 Dec '18

24 Dec '18

See <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-kvm-common-el7-x86_…> ------------------------------------------ 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-kvm-common-el7-x86_…> > 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/changes/59/95959/1:test --prune > git rev-parse origin/test^{commit} # timeout=10 > git rev-parse test^{commit} # timeout=10 Checking out Revision 05b40dfb4ec43a82530e8c471395d1858e5c59e1 (test) > git config core.sparsecheckout # timeout=10 > git checkout -f 05b40dfb4ec43a82530e8c471395d1858e5c59e1 Commit message: "mirror-reposync: remove gluster-3.10 mirror" > git rev-list --no-walk 05b40dfb4ec43a82530e8c471395d1858e5c59e1 # timeout=10 [system-sync_mirrors-centos-kvm-common-el7-x86_64] $ /bin/bash -xe /tmp/jenkins6750021164552250124.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror centos-kvm-common-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 1479, in _commonLoadRepoXML result = self._getFileRepoXML(local, text) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1256, in _getFileRepoXML size=102400) # setting max size as 100K File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1022, in _getFile result = self.grab.urlgrab(misc.to_utf8(relative), local, File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 700, in <lambda> grab = property(lambda self: self._getgrab()) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 695, in _getgrab self._setupGrab() File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 632, in _setupGrab urls = self.urls File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 878, in <lambda> urls = property(fget=lambda self: self._geturls(), File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 875, in _geturls self._baseurlSetup() File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 821, in _baseurlSetup mirrorurls.extend(list(self.metalink_data.urls())) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 918, in <lambda> metalink_data = property(fget=lambda self: self._getMetalink(), File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 897, in _getMetalink raise Errors.RepoError, msg yum.Errors.RepoError: Cannot retrieve metalink for repository: fedora-base-fc29. Please verify its path and try again Build step 'Execute shell' marked build as failure

1 2

[oVirt Jenkins] ovirt-appliance_ovirt-4.3_build-artifacts-el7-x86_64 - Build # 37 - Failure!
by jenkins＠jenkins.phx.ovirt.org 24 Dec '18

24 Dec '18

Project: http://jenkins.ovirt.org/job/ovirt-appliance_ovirt-4.3_build-artifacts-el7-… Build: http://jenkins.ovirt.org/job/ovirt-appliance_ovirt-4.3_build-artifacts-el7-… Build Number: 37 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #37 [Yuval Turgeman] build: change root fs to be a logical volume ----------------- Failed Tests: ----------------- No tests ran.

1 1

[oVirt Jenkins] ovirt-node-ng-image_master_build-artifacts-fc28-x86_64 - Build # 159 - Failure!
by jenkins＠jenkins.phx.ovirt.org 24 Dec '18

24 Dec '18

Project: http://jenkins.ovirt.org/job/ovirt-node-ng-image_master_build-artifacts-fc2… Build: http://jenkins.ovirt.org/job/ovirt-node-ng-image_master_build-artifacts-fc2… Build Number: 159 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #159 [Sandro Bonazzola] automation: add devices for qemu performances ----------------- Failed Tests: ----------------- No tests ran.

1 1

[JIRA] (OVIRT-2593) How does stdci prevent regressions and proactively monitor the cluster?
by Eyal Edri (oVirt JIRA) 24 Dec '18

24 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2593?page=com.atlassian.jira.… ] Eyal Edri commented on OVIRT-2593: ---------------------------------- [~ederevea] I believe we solved some of the issues here and some are in progress, for e.g: We've identified the source for slowness on the UI and its a memory leak on the SSE plugin blue ocean is using, [~dbelenky(a)redhat.com] please add a link to the ticket that refers to that. We've also applied JVM improvements to the master, and limit the session timeout ( it was unlimited so far ). Also, we're working on splitting the kubevirt Jenkins to be independent and not shared with oVirt, tracked on another ticket [~bkorren(a)redhat.com] can add links. We are also planning to add monitoring, hopefully soon, [~ederevea] please add link to the card on it. As for flexibility of the project, we're doing our best with the very limited resources we have available and the number of developers available to contribute. Having said that, we have staging systems and we try to add tests to any new code that we introduce, including testing on staging. > How does stdci prevent regressions and proactively monitor the cluster? > ----------------------------------------------------------------------- > > Key: OVIRT-2593 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2593 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Roman Mohr > Assignee: infra > > We want to go one step further with KubeVirt and sooner or later only merge > when the tests are green (automatically). > Therefore we want to ensure that this CI system is the right system for us > and can be properly scaled, developed and operated. > Apart from requirements like, automatically re-run tests and a merge-pools > stability and QoS of the CI system are interesting for us. > Some examples: > * Sometimes jobs break with a system error shown in the logs (is that > monitored and worked on?) > * Sometimes things like "out-of-disk-space" show up. Is e.g. disk > utilization proactively handled? > * We had one issue where the docker installation was broken in a > build-slot and all jobs stopped fast. As a consequence all following builds > were scheduled there too. Is something like that monitored? > * We repeatedly have issues, connecting to jenkins. It is extremely slow > (not just Blue-Ocean-slow, really slow). Are such things monitored and > alarms raised, countermeasures taken? > * That did not happen for a while, but there were repeatedly bare-metal > machines whithout kvm-nesting added to the cluster. Are there measures in > place which prevent such regressions where the same issues happen multiple > times? > * How is the flexibility of the project ensured? Is it also tested and > maintained in a sane fashion to allow proper evolution in time? Automated > tests? Offline-testing of changes? And so on ... -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100096)

1 0

[JIRA] (OVIRT-2593) How does stdci prevent regressions and proactively monitor the cluster?
by Eyal Edri (oVirt JIRA) 24 Dec '18

24 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2593?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-2593: ----------------------------- Issue Type: Improvement (was: By-EMAIL) > How does stdci prevent regressions and proactively monitor the cluster? > ----------------------------------------------------------------------- > > Key: OVIRT-2593 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2593 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Roman Mohr > Assignee: infra > > We want to go one step further with KubeVirt and sooner or later only merge > when the tests are green (automatically). > Therefore we want to ensure that this CI system is the right system for us > and can be properly scaled, developed and operated. > Apart from requirements like, automatically re-run tests and a merge-pools > stability and QoS of the CI system are interesting for us. > Some examples: > * Sometimes jobs break with a system error shown in the logs (is that > monitored and worked on?) > * Sometimes things like "out-of-disk-space" show up. Is e.g. disk > utilization proactively handled? > * We had one issue where the docker installation was broken in a > build-slot and all jobs stopped fast. As a consequence all following builds > were scheduled there too. Is something like that monitored? > * We repeatedly have issues, connecting to jenkins. It is extremely slow > (not just Blue-Ocean-slow, really slow). Are such things monitored and > alarms raised, countermeasures taken? > * That did not happen for a while, but there were repeatedly bare-metal > machines whithout kvm-nesting added to the cluster. Are there measures in > place which prevent such regressions where the same issues happen multiple > times? > * How is the flexibility of the project ensured? Is it also tested and > maintained in a sane fashion to allow proper evolution in time? Automated > tests? Offline-testing of changes? And so on ... -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100096)

1 0