- Infra - oVirt List Archives

Build failed in Jenkins: system-sync_mirrors-fedora-base-fc29-x86_64 #113
by jenkins＠jenkins.phx.ovirt.org 16 Dec '18

16 Dec '18

See <http://jenkins.ovirt.org/job/system-sync_mirrors-fedora-base-fc29-x86_64/11…> ------------------------------------------ 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-base-fc29-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 176abf92c7f6ef0fb587732da7f1a3d7dc95ac79 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 176abf92c7f6ef0fb587732da7f1a3d7dc95ac79 Commit message: "ost: Add 'COVERAGE' option" > git rev-list --no-walk 176abf92c7f6ef0fb587732da7f1a3d7dc95ac79 # timeout=10 [system-sync_mirrors-fedora-base-fc29-x86_64] $ /bin/bash -xe /tmp/jenkins6309051305063768127.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror fedora-base-fc29 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 914, in _getMetalink self._metalink = metalink.MetaLinkRepoMD(self.metalink_filename) File "/usr/lib/python2.7/site-packages/yum/metalink.py", line 185, in __init__ raise MetaLinkRepoErrorParseFail, "File %s does not exist" %filename yum.metalink.MetaLinkRepoErrorParseFail: File /home/jenkins/mirrors_cache/fedora-base-fc29/metalink.xml does not exist Build step 'Execute shell' marked build as failure

1 1

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

16 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/jenkins4579412541545086385.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 1

[CQ]: 96204,1 (ovirt-node-ng) failed "ovirt-master" system tests
by oVirt Jenkins 16 Dec '18

16 Dec '18

Change 96204,1 (ovirt-node-ng) 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/96204/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/12008/

1 0

[oVirt Jenkins] ovirt-appliance_master_build-artifacts-fc28-x86_64 - Build # 155 - Failure!
by jenkins＠jenkins.phx.ovirt.org 16 Dec '18

16 Dec '18

Project: http://jenkins.ovirt.org/job/ovirt-appliance_master_build-artifacts-fc28-x8… Build: http://jenkins.ovirt.org/job/ovirt-appliance_master_build-artifacts-fc28-x8… Build Number: 155 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #155 [Yuval Turgeman] automation: remove build-artifacts* from stdci-v2 ----------------- Failed Tests: ----------------- No tests ran.

1 1

Build failed in Jenkins: system-sync_mirrors-epel-el6-x86_64 #2141
by jenkins＠jenkins.phx.ovirt.org 16 Dec '18

16 Dec '18

See <http://jenkins.ovirt.org/job/system-sync_mirrors-epel-el6-x86_64/2141/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 176abf92c7f6ef0fb587732da7f1a3d7dc95ac79 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 176abf92c7f6ef0fb587732da7f1a3d7dc95ac79 Commit message: "ost: Add 'COVERAGE' option" > git rev-list --no-walk 176abf92c7f6ef0fb587732da7f1a3d7dc95ac79 # timeout=10 [system-sync_mirrors-epel-el6-x86_64] $ /bin/bash -xe /tmp/jenkins1567165173136959920.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/centos-extras-el7/repomd.xml.old.tmp' Build step 'Execute shell' marked build as failure

1 1

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

16 Dec '18

Good morning! Attached is the HTML page with the jenkins status report. You can see it also here: - http://jenkins.ovirt.org/job/system_jenkins-report/675//artifact/exported-a… Cheers, Jenkins

1 0

Build failed in Jenkins: system-sync_mirrors-centos-qemu-ev-release-el7-x86_64 #1603
by jenkins＠jenkins.phx.ovirt.org 15 Dec '18

15 Dec '18

See <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-qemu-ev-release-el7…> ------------------------------------------ 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-qemu-ev-release-el7…> > 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 176abf92c7f6ef0fb587732da7f1a3d7dc95ac79 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 176abf92c7f6ef0fb587732da7f1a3d7dc95ac79 Commit message: "ost: Add 'COVERAGE' option" > git rev-list --no-walk 176abf92c7f6ef0fb587732da7f1a3d7dc95ac79 # timeout=10 [system-sync_mirrors-centos-qemu-ev-release-el7-x86_64] $ /bin/bash -xe /tmp/jenkins6055236266178166493.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror centos-qemu-ev-release-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 1039, in _getFile raise e yum.Errors.NoMoreMirrorsRepoError: failure: repodata/repomd.xml from centos-qemu-ev-release-el7: [Errno 256] No more mirrors to try. http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2607:f128:40:1600:225:90ff:fe00:bde6: Network is unreachable" http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2607:f128:40:1600:225:90ff:fe00:bde6: Network is unreachable" http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2607:f128:40:1600:225:90ff:fe00:bde6: Network is unreachable" http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2607:f128:40:1600:225:90ff:fe00:bde6: Network is unreachable" http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2607:f128:40:1600:225:90ff:fe00:bde6: Network is unreachable" http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2607:f128:40:1600:225:90ff:fe00:bde6: Network is unreachable" http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2607:f128:40:1600:225:90ff:fe00:bde6: Network is unreachable" http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2607:f128:40:1600:225:90ff:fe00:bde6: Network is unreachable" http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2607:f128:40:1600:225:90ff:fe00:bde6: Network is unreachable" http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2607:f128:40:1600:225:90ff:fe00:bde6: Network is unreachable" Build step 'Execute shell' marked build as failure

1 1

[JIRA] (OVIRT-1835) Create an automated update mechanism for slaves
by Barak Korren (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1835?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-1835: ------------------------------------- Even if slaves are ephemeral, you need an update mecahnism for the base image. Even more so then in non-ephemeral ones... בתאריך שבת, 15 בדצמ׳ 2018, 17:25, מאת Eyal Edri (oVirt JIRA) < > Create an automated update mechanism for slaves > ----------------------------------------------- > > Key: OVIRT-1835 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1835 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins Slaves > Reporter: Barak Korren > Assignee: infra > Labels: slaves > > While we already have an automated mechanism for controlling the YUM/DNF repo configuration on slaves, and we also already have a way to install or update components that are critical to the CI system (Both are provided by '{{global-setup.sh}}'), we're lacking a mechanism that can apply general system updates, and more importantly, kernel updates to slaves. > Some things we'd like such a mechanism to provide: > * Require a minimal amount of manual work (Best case scenario - nothing more then merging a repository update patch would be needed). > * Test updated slaves before putting them back to production use > * Allow rolling back failed updates -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-1835) Create an automated update mechanism for slaves
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1835?page=com.atlassian.jira.… ] Eyal Edri commented on OVIRT-1835: ---------------------------------- I'm not sure we need to invest in this if the aim is to more to ephemeral slaves, either containers or VMs. > Create an automated update mechanism for slaves > ----------------------------------------------- > > Key: OVIRT-1835 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1835 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins Slaves > Reporter: Barak Korren > Assignee: infra > Labels: slaves > > While we already have an automated mechanism for controlling the YUM/DNF repo configuration on slaves, and we also already have a way to install or update components that are critical to the CI system (Both are provided by '{{global-setup.sh}}'), we're lacking a mechanism that can apply general system updates, and more importantly, kernel updates to slaves. > Some things we'd like such a mechanism to provide: > * Require a minimal amount of manual work (Best case scenario - nothing more then merging a repository update patch would be needed). > * Test updated slaves before putting them back to production use > * Allow rolling back failed updates -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

2 1

[JIRA] (OVIRT-2521) enable stdci v2 for ovirt-web-ui
by Greg Sheremeta (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2521?page=com.atlassian.jira.… ] Greg Sheremeta updated OVIRT-2521: ---------------------------------- Resolution: Fixed Status: Done (was: To Do) > enable stdci v2 for ovirt-web-ui > -------------------------------- > > Key: OVIRT-2521 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2521 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Greg Sheremeta > Assignee: infra > > Hi, > I want to enable stdci v2 for ovirt-web-ui, to run alongside travis, so we > can easily make rpms from PRs. > I added automation.yaml [1] and updated standard_pipelines [2]. > 1 - is there anything else I need to do? > 2 - is there a way to configure this to be on-demand only? in other words, > only run when we invoke 'ci build please'? > 2a - if not, is there a way to make ovirt ci non-blocking since travis > would still be our source of truth? > [1] https://github.com/oVirt/ovirt-web-ui/pull/794 > [2] > https://gerrit.ovirt.org/#/c/94639/1/jobs/confs/projects/standard-pipelines… > -- > GREG SHEREMETA > SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX > Red Hat NA > <https://www.redhat.com/> > gshereme(a)redhat.com IRC: gshereme > <https://red.ht/sig> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2521) enable stdci v2 for ovirt-web-ui
by Greg Sheremeta (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2521?page=com.atlassian.jira.… ] Greg Sheremeta commented on OVIRT-2521: --------------------------------------- Yep, done, all set. For posterity, ovirt-web-ui is using travis as truth but also using ovirt ci for RPMs only. check-patch and check-merged are empty, and we just use "ci build please" to make RPMs. > enable stdci v2 for ovirt-web-ui > -------------------------------- > > Key: OVIRT-2521 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2521 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Greg Sheremeta > Assignee: infra > > Hi, > I want to enable stdci v2 for ovirt-web-ui, to run alongside travis, so we > can easily make rpms from PRs. > I added automation.yaml [1] and updated standard_pipelines [2]. > 1 - is there anything else I need to do? > 2 - is there a way to configure this to be on-demand only? in other words, > only run when we invoke 'ci build please'? > 2a - if not, is there a way to make ovirt ci non-blocking since travis > would still be our source of truth? > [1] https://github.com/oVirt/ovirt-web-ui/pull/794 > [2] > https://gerrit.ovirt.org/#/c/94639/1/jobs/confs/projects/standard-pipelines… > -- > GREG SHEREMETA > SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX > Red Hat NA > <https://www.redhat.com/> > gshereme(a)redhat.com IRC: gshereme > <https://red.ht/sig> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2305) Clean up dead slaves from the staging Jenkins
by Barak Korren (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2305?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-2305: ------------------------------------- Yes. בתאריך שבת, 15 בדצמ׳ 2018, 18:02, מאת Eyal Edri (oVirt JIRA) < > Clean up dead slaves from the staging Jenkins > --------------------------------------------- > > Key: OVIRT-2305 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2305 > Project: oVirt - virtualization made easy > Issue Type: Outage > Components: Staging infra > Reporter: Barak Korren > Assignee: infra > -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2305) Clean up dead slaves from the staging Jenkins
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2305?page=com.atlassian.jira.… ] Eyal Edri commented on OVIRT-2305: ---------------------------------- still needed? > Clean up dead slaves from the staging Jenkins > --------------------------------------------- > > Key: OVIRT-2305 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2305 > Project: oVirt - virtualization made easy > Issue Type: Outage > Components: Staging infra > Reporter: Barak Korren > Assignee: infra > -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

2 1

[JIRA] (OVIRT-2616) Rawhide build failed, not logs available
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2616?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-2616: ----------------------------- Resolution: Won't Fix Status: Done (was: To Do) we stopped supporting the fcraw distro due to multiple issues and unavailable resources to support this going forward. please use latest fc28 or fc29 ( which should be added soon if not added already ). > Rawhide build failed, not logs available > ---------------------------------------- > > Key: OVIRT-2616 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2616 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Nir Soffer > Assignee: infra > > https://jenkins.ovirt.org/job/ovirt-imageio_standard-check-patch/723/artifa… > https://jenkins.ovirt.org/job/ovirt-imageio_standard-check-patch/723//artif… > returns 404 > The next builds on this topic succeeded, so it probably was a temporary > error. Do we have any other > log that can explain what happened on the slave running the rawhide build? > Nir -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2148) 005_network_by_label.assign_hosts_network_label
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2148?page=com.atlassian.jira.… ] Eyal Edri closed OVIRT-2148. ---------------------------- Resolution: Cannot Reproduce (was: Fixed) > 005_network_by_label.assign_hosts_network_label > ------------------------------------------------ > > Key: OVIRT-2148 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2148 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Dafna Ron > Assignee: infra > Labels: ost_failures, ost_race > > Change 91614,10 (ovirt-provider-ovn) 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/91614/10 > For failed test results see: > http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/2312/ > Fault reason is "Operation Failed". Fault detail is "[Cannot add Label. Another Setup Networks or Host Refresh process in progress on the host. Please try later.]". HTTP response code is 409. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2182) Create timed jobs
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2182?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-2182: ----------------------------- Resolution: Incomplete Status: Done (was: To Do) > Create timed jobs > ----------------- > > Key: OVIRT-2182 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2182 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Gal Ben Haim > Assignee: infra > > The timed jobs should use fc28 mock, so we will also test ovirt engine SDK. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2195) race in 004_basic_sanity.verify_vm_import on master CQ
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2195?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-2195: ----------------------------- Resolution: Cannot Reproduce Status: Done (was: To Do) > race in 004_basic_sanity.verify_vm_import on master CQ > ------------------------------------------------------ > > Key: OVIRT-2195 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2195 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Dafna Ron > Assignee: infra > Labels: ost_failures, ost_race > > We have a race that causes test: 004_basic_sanity.verify_vm_import to fail > This build: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/8183/ failed but there is nothing in the log to suggest that the import failed. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2264) Cannot deactivate Storage while there are running tasks on this Storage
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2264?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-2264: ----------------------------- Resolution: Cannot Reproduce Status: Done (was: To Do) > Cannot deactivate Storage while there are running tasks on this Storage > ----------------------------------------------------------------------- > > Key: OVIRT-2264 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2264 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Dafna Ron > Assignee: infra > Labels: ost_failures, ost_race > > we failed test: 007_sd_reattach.deactivate_storage_domain in vdsm project with error: Cannot deactivate Storage while there are running tasks on this Storage. -Please wait until tasks will finish and try again.]". HTTP response code is 409. > I am opening this as a race in case something changed in OST tests which would cause this to repeat. > https://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/2506 > https://gerrit.ovirt.org/#/c/92313/2 -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2309) Update Gerrit infra-docs how to add STDCI V2 jobs
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2309?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-2309: ----------------------------- Resolution: Fixed Status: Done (was: To Do) https://ovirt-infra-docs.readthedocs.io/en/latest/CI/STDCI-Configuration/in… > Update Gerrit infra-docs how to add STDCI V2 jobs > ------------------------------------------------- > > Key: OVIRT-2309 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2309 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Daniel Belenky > Assignee: infra > > As an STDCI user, I want to see clear documentation about adding new projects to STDCI so that I can setup STDCI for my project. Currently, the Gerrit documentation explains how to setup STDCI V1 only. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2326) Use containers to scale bare-metal slaves
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2326?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-2326: ----------------------------- Resolution: Fixed Status: Done (was: To Do) all issues in the Epic are solved. > Use containers to scale bare-metal slaves > ----------------------------------------- > > Key: OVIRT-2326 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2326 > Project: oVirt - virtualization made easy > Issue Type: Epic > Reporter: Gal Ben Haim > Assignee: infra > Priority: Highest > > We want to run containers on the bare-metal hosts so we can use them for multiple tasks in parallel. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2402) ioprocess failed ovirt-master with 500 error from engine
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2402?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-2402: ----------------------------- Resolution: Cannot Reproduce Status: Done (was: To Do) > ioprocess failed ovirt-master with 500 error from engine > -------------------------------------------------------- > > Key: OVIRT-2402 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2402 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Dafna Ron > Assignee: infra > Labels: ost_failures, ost_race > > 004_basic_sanity.run_vms failed with Internal Server Error from engine. > Looking at engine and server logs I actually do not see any issue with engine or the machine itself but there is a 500 reply to the API. > I think the issue is that the api got a 500 reply from engine but I am not seeing a reason why so this needs to be investigated further. > I am keeping build logs and will look at it later on > https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/8971/ -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2425) ovirt-guest-agent missing in 4.2 tested / snapshot repo
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2425?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-2425: ----------------------------- Resolution: Incomplete Status: Done (was: To Do) no reply, please reopen if this is still an issue. > ovirt-guest-agent missing in 4.2 tested / snapshot repo > ------------------------------------------------------- > > Key: OVIRT-2425 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2425 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: infra > > Hi, > ovirt-guest-agent*.rpm > are missing in > https://resources.ovirt.org/pub/ovirt-4.2-snapshot/rpm/el7/noarch/ and in > https://resources.ovirt.org/repos/ovirt/tested/4.2/rpm/el7/noarch/ > The build > https://jenkins.ovirt.org/job/ovirt-guest-agent_4.2_build-artifacts-el7-x86… > completed with success on Feb 6, 2018 and contains it. > can you please check why it's missing and get it published? > can you also please check why we have not been warned a package is missing > from our repos? > Thanks > -- > SANDRO BONAZZOLA > MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV > Red Hat EMEA <https://www.redhat.com/> > sbonazzo(a)redhat.com > <https://red.ht/sig> > <https://www.redhat.com/en/events/red-hat-open-source-day-italia?sc_cid=701f…> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2482) ovirt-node-ng on ovirt-master failure on test verify_suspend_resume_vm0
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2482?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-2482: ----------------------------- Resolution: Cannot Reproduce Status: Done (was: To Do) > ovirt-node-ng on ovirt-master failure on test verify_suspend_resume_vm0 > ----------------------------------------------------------------------- > > Key: OVIRT-2482 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2482 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Dafna Ron > Assignee: infra > Labels: ost_failures, ost_race > > http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/10175/ > The change reported is not related to the failure. > I can see the failure is due to host0 responding with an invalid argument (which many just mean the host is not responding but seems like a reporting exception related to virt team) > https://pastebin.com/pm6x0W62 -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2498) Failing KubeVirt CI
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2498?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-2498: ----------------------------- Resolution: Fixed Status: Done (was: To Do) > Failing KubeVirt CI > ------------------- > > Key: OVIRT-2498 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2498 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: CI client projects > Reporter: Petr Kotas > Assignee: infra > > Hi, > I am working on fixing the issues on the KubeVirt e2e test suites. This > task is directly related to unstable CI, due to unknown errors. > The progress is reported in the CNV trello: > https://trello.com/c/HNXcMEQu/161-epic-improve-ci > I am creating this issue since the KubeVirt experience random timeouts on > random tests most of the times when test suites run. > The issue from outside is showing as timeouts on difference part of tests. > Sometimes the tests fails in set up phase, again due to random timeout. > The example in the link bellow timed out for network connection on > localhost. > [check-patch.k8s-1.11.0-dev.el7.x86_64] > requests.exceptions.ReadTimeout: > UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. > (read timeout=60) > Example of failing test suites is here > https://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/1916/cons… > The list of errors related to the failing CI can be found in my notes > https://docs.google.com/document/d/1_ll1DOMHgCRHn_Df9i4uvtRFyMK-bDCHEeGfJFT… > I am not sure whether KubeVirt already shared the resource requirements, so > I provide short summary: > *Resources for KubeVirt e2e tests:* > - at least 12GB of RAM - we start 3 nodes (3 docker images) each require > 4GB of RAM > - exposed /dev/kvm to enable native virtualization > - cached images, since these are used to build the test cluster: > - kubevirtci/os-3.10.0-crio:latest > - kubevirtci/os-3.10.0-multus:latest > - kubevirtci/os-3.10.0:latest > - kubevirtci/k8s-1.10.4:latest > - kubevirtci/k8s-multus-1.11.1:latest > - kubevirtci/k8s-1.11.0:latest > How can we overcome this? Can we work together to build a suitable > requirements for running the tests so it passes each time? > Kind regards, > Petr Kotas -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2498) Failing KubeVirt CI
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2498?page=com.atlassian.jira.… ] Eyal Edri commented on OVIRT-2498: ---------------------------------- [~pkotas] we've since then migrated the KubeVirt CI to run inside OpenShift, if you're still interested in the load / stats, reach out to [~ederevea] or [~gbenhaim(a)redhat.com] which are actively working on profiling and monitoring the infra and tests. > Failing KubeVirt CI > ------------------- > > Key: OVIRT-2498 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2498 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: CI client projects > Reporter: Petr Kotas > Assignee: infra > > Hi, > I am working on fixing the issues on the KubeVirt e2e test suites. This > task is directly related to unstable CI, due to unknown errors. > The progress is reported in the CNV trello: > https://trello.com/c/HNXcMEQu/161-epic-improve-ci > I am creating this issue since the KubeVirt experience random timeouts on > random tests most of the times when test suites run. > The issue from outside is showing as timeouts on difference part of tests. > Sometimes the tests fails in set up phase, again due to random timeout. > The example in the link bellow timed out for network connection on > localhost. > [check-patch.k8s-1.11.0-dev.el7.x86_64] > requests.exceptions.ReadTimeout: > UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. > (read timeout=60) > Example of failing test suites is here > https://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/1916/cons… > The list of errors related to the failing CI can be found in my notes > https://docs.google.com/document/d/1_ll1DOMHgCRHn_Df9i4uvtRFyMK-bDCHEeGfJFT… > I am not sure whether KubeVirt already shared the resource requirements, so > I provide short summary: > *Resources for KubeVirt e2e tests:* > - at least 12GB of RAM - we start 3 nodes (3 docker images) each require > 4GB of RAM > - exposed /dev/kvm to enable native virtualization > - cached images, since these are used to build the test cluster: > - kubevirtci/os-3.10.0-crio:latest > - kubevirtci/os-3.10.0-multus:latest > - kubevirtci/os-3.10.0:latest > - kubevirtci/k8s-1.10.4:latest > - kubevirtci/k8s-multus-1.11.1:latest > - kubevirtci/k8s-1.11.0:latest > How can we overcome this? Can we work together to build a suitable > requirements for running the tests so it passes each time? > Kind regards, > Petr Kotas -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2478) CQ Master Failure - oVirt engine missing packages
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2478?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-2478: ----------------------------- Resolution: Cannot Reproduce Status: Done (was: To Do) > CQ Master Failure - oVirt engine missing packages > ------------------------------------------------- > > Key: OVIRT-2478 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2478 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Ehud Yonasi > Assignee: infra > > There were failures in installing ovirt-engine for missing packages: > nimbus-jose-jwt > json-smart > Like this failure: > http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/10113/console > I've sent a patch to fix that to ost: > https://gerrit.ovirt.org/#/c/94183/ -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2505) ovirt github organization
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2505?page=com.atlassian.jira.… ] Eyal Edri commented on OVIRT-2505: ---------------------------------- Is this still needed? > ovirt github organization > ------------------------- > > Key: OVIRT-2505 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2505 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Ahmad Khiet > Assignee: infra > > Hi, > can you please add my github user to ovirt org > https://github.com/NaySoftware > Thanks, > Ahmad. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2506) Accessing logs is sometimes extremely slow even without blueocean
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2506?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-2506: ----------------------------- Resolution: Cannot Reproduce Status: Done (was: To Do) We introduced various improvements for Jenkins master to handle this, also we found a memory leak in one of the blueoceans plugins which we're tracking a fix on GitHub for it. if you can reproduce the slowness please reopen once it happens so we'll be able to debug it on live system. > Accessing logs is sometimes extremely slow even without blueocean > ----------------------------------------------------------------- > > Key: OVIRT-2506 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2506 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Components: Jenkins Master > Reporter: Roman Mohr > Assignee: infra > > Hi, > With the switch from blueocean to the text-based build summary in > kubevirt/kubevirt, in general accessing works much better. Still > especially in the morning hours it can take a long time to access the > logs. > Can it be that the build summary and the logs are still served by > jenkins? If yes, would it help to copied out/cache/serve the build > logs via a dedicated webserver? > Best Regards, > Roman -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2521) enable stdci v2 for ovirt-web-ui
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2521?page=com.atlassian.jira.… ] Eyal Edri commented on OVIRT-2521: ---------------------------------- [~gshereme(a)redhat.com] was this done? any help is still needed? > enable stdci v2 for ovirt-web-ui > -------------------------------- > > Key: OVIRT-2521 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2521 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Greg Sheremeta > Assignee: infra > > Hi, > I want to enable stdci v2 for ovirt-web-ui, to run alongside travis, so we > can easily make rpms from PRs. > I added automation.yaml [1] and updated standard_pipelines [2]. > 1 - is there anything else I need to do? > 2 - is there a way to configure this to be on-demand only? in other words, > only run when we invoke 'ci build please'? > 2a - if not, is there a way to make ovirt ci non-blocking since travis > would still be our source of truth? > [1] https://github.com/oVirt/ovirt-web-ui/pull/794 > [2] > https://gerrit.ovirt.org/#/c/94639/1/jobs/confs/projects/standard-pipelines… > -- > GREG SHEREMETA > SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX > Red Hat NA > <https://www.redhat.com/> > gshereme(a)redhat.com IRC: gshereme > <https://red.ht/sig> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2545) Fwd: [ovirt-users] Backport KVM bug fix for nested KVM in ESXi and Hyper-V
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2545?page=com.atlassian.jira.… ] Eyal Edri reassigned OVIRT-2545: -------------------------------- Assignee: Marc Dequènes (Duck) (was: infra) Hi Duck, Can you check if this is still needed? > Fwd: [ovirt-users] Backport KVM bug fix for nested KVM in ESXi and Hyper-V > -------------------------------------------------------------------------- > > Key: OVIRT-2545 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2545 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: Marc Dequènes (Duck) > > Opening a ticket because looks like the forwarded email doesn't show up on > list archives at > https://lists.ovirt.org/archives/list/users@ovirt.org/2018/10/ > Marc can you please check? > ---------- Forwarded message --------- > From: Gianluca Cecchi <gianluca.cecchi(a)gmail.com> > Date: mar 16 ott 2018 alle ore 12:57 > Subject: [ovirt-users] Backport KVM bug fix for nested KVM in ESXi and > Hyper-V > To: users <users(a)ovirt.org> > Hello, > I send a dedicated subject message on this topic. > Also, the reply to my other related message seems not visible inside list > archive page for some reason. > It seems this nasty problem in nested virt using pc-i440fx-rhel7.X.0 > machine type with X >= 3 impacts not only vSphere as main hypervisor for > nested KVM, but other hypervisors too (Hyper-V) and other machine types too > and could be due to a bug in KVM, so in the kernel, if I understood > correctly. > According to this link below > https://bugs.launchpad.net/qemu/+bug/1636217 > and its comment by Roman Kagan in June this year: > " > This is a KVM bug. It has been fixed in mainstream Linux in > commit d391f1207067268261add0485f0f34503539c5b0 > Author: Vitaly Kuznetsov <email address hidden> > Date: Thu Jan 25 16:37:07 2018 +0100 > x86/kvm/vmx: do not use vm-exit instruction length for fast MMIO when > running nested > I was investigating an issue with seabios >= 1.10 which stopped working > for nested KVM on Hyper-V. The problem appears to be in > handle_ept_violation() function: when we do fast mmio we need to skip > the instruction so we do kvm_skip_emulated_instruction(). This, however, > depends on VM_EXIT_INSTRUCTION_LEN field being set correctly in VMCS. > However, this is not the case. > Intel's manual doesn't mandate VM_EXIT_INSTRUCTION_LEN to be set when > EPT MISCONFIG occurs. While on real hardware it was observed to be set, > some hypervisors follow the spec and don't set it; we end up advancing > IP with some random value. > I checked with Microsoft and they confirmed they don't fill > VM_EXIT_INSTRUCTION_LEN on EPT MISCONFIG. > Fix the issue by doing instruction skip through emulator when running > nested. > Fixes: 68c3b4d1676d870f0453c31d5a52e7e65c7448ae > Suggested-by: Radim Krčmář <email address hidden> > Suggested-by: Paolo Bonzini <email address hidden> > Signed-off-by: Vitaly Kuznetsov <email address hidden> > Acked-by: Michael S. Tsirkin <email address hidden> > Signed-off-by: Radim Krčmář <email address hidden> > Although the commit mentions Hyper-V as L0 hypervisor, the same problem > pertains to ESXi. > The commit is included in v4.16. > " > Is it possible to backport the fix to the kernel provided by plain > RHEL/CentOS hosts and/or RHVH/ovirt-ng nodes? > Thanks, > Gianluca > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/V6PLM7USQ4WJX… > -- > SANDRO BONAZZOLA > MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV > Red Hat EMEA <https://www.redhat.com/> > sbonazzo(a)redhat.com > <https://red.ht/sig> > <https://www.redhat.com/en/events/red-hat-open-source-day-italia?sc_cid=701f…> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2547) Fedora 28/rawhide job fail with: "Job for systemd-journald.service failed"
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2547?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-2547: ----------------------------- Resolution: Done Status: Done (was: To Do) no reply from requestor, please reopen if needed. > Fedora 28/rawhide job fail with: "Job for systemd-journald.service failed" > -------------------------------------------------------------------------- > > Key: OVIRT-2547 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2547 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Nir Soffer > Assignee: infra > > These jobs failed without running any test and no logs were collected. > 1. 00:04:17.045 [check-patch.fc28.x86_64] Job for systemd-journald.service > failed. See "systemctl status systemd-journald.service" and "journalctl > -xe" for details. > https://jenkins.ovirt.org/job/ovirt-imageio_standard-check-patch/617/consol… > 2. 00:01:40.814 [check-patch.fcraw.x86_64] Job for systemd-journald.service > failed because a fatal signal was delivered to the control process. See > "systemctl status systemd-journald.service" and "journalctl -xe" for > details. > https://jenkins.ovirt.org/job/ovirt-imageio_standard-check-patch/618/consol… > 3. 00:07:15.919 [check-patch.fc28.x86_64] Job for systemd-journald.service > failed because a fatal signal was delivered to the control process. See > "systemctl status systemd-journald.service" and "journalctl -xe" for > details. > https://jenkins.ovirt.org/job/ovirt-imageio_standard-check-patch/627/consol… > Can we flag this kind of failure as CI error instead of test failure? > Nir -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2556) kubevirt test runs and nested docker issue
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2556?page=com.atlassian.jira.… ] Eyal Edri commented on OVIRT-2556: ---------------------------------- Is this still happening? [~dbelenky(a)redhat.com] [~bkorren(a)redhat.com]? > kubevirt test runs and nested docker issue > ------------------------------------------ > > Key: OVIRT-2556 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2556 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Roman Mohr > Assignee: infra > Priority: High > > Hi, > we see a lot of tests which fail with during the setup [1] : > ``` > /usr/bin/docker-current: Error response from daemon: grpc: the > connection is unavailable. > time="2018-10-23T07:17:55Z" level=error msg="error getting events from > daemon: context canceled" > ``` > It looks like the docker daemon may not run properly. > Best Regards, > Roman > [1] https://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/2344//art… -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-1840) jobs freeze due to unresponsive docker
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1840?page=com.atlassian.jira.… ] Eyal Edri commented on OVIRT-1840: ---------------------------------- Is it still happening? > jobs freeze due to unresponsive docker > -------------------------------------- > > Key: OVIRT-1840 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1840 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Evgheni Dereveanchin > Assignee: infra > > Quite often do I see jobs stuck at various stages for hours that seem related to docker. > Example: > http://jenkins.ovirt.org/job/ovirt-engine_master_build-artifacts-fc26-x86_6… > There's multiple docker commands stuck on the slave (will post in the next comment) so it seems to be deadlocked. Opening ticket to investigate which step exactly is causing this and possible ways of resolving. The job in question doesn't even use docker so shouldn't suffer if this happens. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-1832) Vdsm make install on fc27 fails with "package vdsm-... is disabled"
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1832?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-1832: ----------------------------- Resolution: Cannot Reproduce Status: Done (was: To Do) > Vdsm make install on fc27 fails with "package vdsm-... is disabled" > ------------------------------------------------------------------- > > Key: OVIRT-1832 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1832 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Nir Soffer > Assignee: infra > > Never seen this error, can anyone explain it? > http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-x86_64/578/console > *00:13:42.747* Problem 1: conflicting requests*00:13:42.747* - > nothing provides vdsm-hook-vmfex-dev = 4.20.11-12.git7f9589a1f.fc27 > needed by vdsm-4.20.11-12.git7f9589a1f.fc27.x86_64*00:13:42.747* > Problem 2: conflicting requests*00:13:42.747* - nothing provides > vdsm-python = 4.20.11-12.git7f9589a1f.fc27 needed by > vdsm-client-4.20.11-12.git7f9589a1f.fc27.noarch*00:13:42.747* Problem > 3: conflicting requests*00:13:42.747* - package > vdsm-gluster-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.748* Problem 4: conflicting requests*00:13:42.748* > - package vdsm-hook-allocate_net-4.20.11-12.git7f9589a1f.fc27.noarch > is disabled*00:13:42.748* Problem 5: conflicting > requests*00:13:42.748* - package > vdsm-hook-boot_hostdev-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.748* Problem 6: conflicting requests*00:13:42.748* > - package vdsm-hook-checkimages-4.20.11-12.git7f9589a1f.fc27.noarch > is disabled*00:13:42.748* Problem 7: conflicting > requests*00:13:42.748* - package > vdsm-hook-checkips-4.20.11-12.git7f9589a1f.fc27.x86_64 is > disabled*00:13:42.748* Problem 8: conflicting requests*00:13:42.748* > - package vdsm-hook-cpuflags-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.748* Problem 9: conflicting requests*00:13:42.748* > - package vdsm-hook-diskunmap-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.749* Problem 10: conflicting requests*00:13:42.749* > - package vdsm-hook-ethtool-options-4.20.11-12.git7f9589a1f.fc27.noarch > is disabled*00:13:42.749* Problem 11: conflicting > requests*00:13:42.749* - package > vdsm-hook-extnet-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.749* Problem 12: conflicting requests*00:13:42.749* > - package vdsm-hook-extra-ipv4-addrs-4.20.11-12.git7f9589a1f.fc27.x86_64 > is disabled*00:13:42.749* Problem 13: conflicting > requests*00:13:42.749* - package > vdsm-hook-fakesriov-4.20.11-12.git7f9589a1f.fc27.x86_64 is > disabled*00:13:42.749* Problem 14: conflicting requests*00:13:42.749* > - package vdsm-hook-fakevmstats-4.20.11-12.git7f9589a1f.fc27.noarch > is disabled*00:13:42.749* Problem 15: conflicting > requests*00:13:42.749* - package > vdsm-hook-faqemu-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.750* Problem 16: conflicting requests*00:13:42.750* > - package vdsm-hook-fcoe-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.750* Problem 17: conflicting requests*00:13:42.750* > - package vdsm-hook-fileinject-4.20.11-12.git7f9589a1f.fc27.noarch > is disabled*00:13:42.750* Problem 18: conflicting > requests*00:13:42.750* - package > vdsm-hook-floppy-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.750* Problem 19: conflicting requests*00:13:42.750* > - package vdsm-hook-httpsisoboot-4.20.11-12.git7f9589a1f.fc27.noarch > is disabled*00:13:42.750* Problem 20: conflicting > requests*00:13:42.750* - package > vdsm-hook-ipv6-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.750* Problem 21: conflicting requests*00:13:42.750* > - package vdsm-hook-isolatedprivatevlan-4.20.11-12.git7f9589a1f.fc27.noarch > is disabled*00:13:42.751* Problem 22: conflicting > requests*00:13:42.751* - package > vdsm-hook-localdisk-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.751* Problem 23: conflicting requests*00:13:42.751* > - package vdsm-hook-macbind-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.751* Problem 24: conflicting requests*00:13:42.751* > - package vdsm-hook-macspoof-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.751* Problem 25: conflicting requests*00:13:42.751* > - package vdsm-hook-nestedvt-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.751* Problem 26: conflicting requests*00:13:42.751* > - package vdsm-hook-noipspoof-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.751* Problem 27: conflicting requests*00:13:42.751* > - package vdsm-hook-numa-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.752* Problem 28: conflicting requests*00:13:42.752* > - package vdsm-hook-openstacknet-4.20.11-12.git7f9589a1f.fc27.noarch > is disabled*00:13:42.752* Problem 29: conflicting > requests*00:13:42.752* - package > vdsm-hook-pincpu-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.752* Problem 30: conflicting requests*00:13:42.752* > - package vdsm-hook-promisc-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.752* Problem 31: conflicting requests*00:13:42.752* > - package vdsm-hook-qemucmdline-4.20.11-12.git7f9589a1f.fc27.noarch > is disabled*00:13:42.752* Problem 32: conflicting > requests*00:13:42.752* - package > vdsm-hook-qos-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.752* Problem 33: conflicting requests*00:13:42.752* > - package vdsm-hook-scratchpad-4.20.11-12.git7f9589a1f.fc27.noarch > is disabled*00:13:42.753* Problem 34: conflicting > requests*00:13:42.753* - package > vdsm-hook-smbios-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.753* Problem 35: conflicting requests*00:13:42.753* > - package vdsm-hook-spiceoptions-4.20.11-12.git7f9589a1f.fc27.noarch > is disabled*00:13:42.753* Problem 36: conflicting > requests*00:13:42.753* - package > vdsm-hook-vfio-mdev-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.753* Problem 37: conflicting requests*00:13:42.753* > - package vdsm-hook-vhostmd-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.753* Problem 38: conflicting requests*00:13:42.753* > - package vdsm-hook-vmdisk-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.753* Problem 39: conflicting requests*00:13:42.754* > - package vdsm-hook-vmfex-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.754* Problem 40: conflicting requests*00:13:42.754* > - package vdsm-hook-vmfex-dev-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.754* Problem 41: conflicting requests*00:13:42.754* > - package vdsm-http-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.754* Problem 42: conflicting requests*00:13:42.754* > - package vdsm-jsonrpc-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.754* Problem 43: conflicting requests*00:13:42.754* > - package vdsm-network-4.20.11-12.git7f9589a1f.fc27.x86_64 is > disabled*00:13:42.754* Problem 44: conflicting requests*00:13:42.754* > - package vdsm-python-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.754* Problem 45: conflicting requests*00:13:42.755* > - package vdsm-tests-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled*00:13:42.755* Problem 46: conflicting requests*00:13:42.755* > - package vdsm-yajsonrpc-4.20.11-12.git7f9589a1f.fc27.noarch is > disabled -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-1874) Manual building UI
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1874?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-1874: ----------------------------- Resolution: Incomplete Status: Done (was: To Do) not reply from the requestor, please reopen with more info if its still needed. > Manual building UI > ------------------ > > Key: OVIRT-1874 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1874 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Standard CI (Pipelines) > Reporter: Lev Veyde > Assignee: infra > Labels: builds, releases > > Hi, > We need the interface to be able to do manual builds from specific refs > (i.e. tag/hash) for the projects. > Thanks, > -- > 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> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-1427) Dependencies between ovirt-engine and vdsm-jsonrpc-java
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1427?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-1427: ----------------------------- Resolution: Won't Fix Status: Done (was: To Do) Yes, there can be occasions of dependency issues, but they are not common. We don't have plans currently to introduce a dependency management in CI, due to lack of resources and other priorities. If this will become possible in the future, we'll consider revisiting this. > Dependencies between ovirt-engine and vdsm-jsonrpc-java > ------------------------------------------------------- > > Key: OVIRT-1427 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1427 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Change Queue > Reporter: Piotr Kliczewski > Assignee: infra > > Recently we had and issue that newer version of vdsm-jsonrpc-java was > available but engine spec was not updated yet. Engine patch contained spec > and module.xml changes which provided dependencies required by new version > of jsonrpc. CI used the new version of jsonrpc without engine patch being > merged which caused several issues. > This ticket is open to track how we could mitigate similar issues in the > future. > Thanks, > Piotr -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-1834) Jenkins failure - perhaps bad permissions
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1834?page=com.atlassian.jira.… ] Eyal Edri commented on OVIRT-1834: ---------------------------------- [~gbenhaim@redhat.com][~grosenth@redhat.com] can this failure still happen or with the latest lago release its fixed? > Jenkins failure - perhaps bad permissions > ----------------------------------------- > > Key: OVIRT-1834 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1834 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Yedidyah Bar David > Assignee: infra > > http://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-tests… > *10:53:01* ERROR: Error fetching remote repo 'origin'*10:53:01* > hudson.plugins.git.GitException: Failed to fetch from > git://gerrit.ovirt.org/ovirt-system-tests.git*10:53:01* at > hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:825)*10:53:01* at > hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1092)*10:53:01* > at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1123)*10:53:01* at > org.jenkinsci.plugins.multiplescms.MultiSCM.checkout(MultiSCM.java:143)*10:53:01* > at hudson.scm.SCM.checkout(SCM.java:495)*10:53:01* at > hudson.model.AbstractProject.checkout(AbstractProject.java:1202)*10:53:01* > at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)*10:53:01* > at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)*10:53:01* > at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)*10:53:01* > at hudson.model.Run.execute(Run.java:1724)*10:53:01* at > hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)*10:53:01* at > hudson.model.ResourceController.execute(ResourceController.java:97)*10:53:01* > at hudson.model.Executor.run(Executor.java:421)*10:53:01* Caused by: > hudson.plugins.git.GitException: Command "git clean -fdx" returned > status code 1:*10:53:01* stdout: Removing > basic-suite-master/LagoInitFile*10:53:01* Removing > basic-suite-master/extra_sources*10:53:01* Removing > basic-suite-master/reposync-config.repo_repoclosure*10:53:01* Removing > basic-suite-master/test-scenarios/000_check_repo_closure.pyc*10:53:01* > Removing basic-suite-master/test-scenarios/001_initialize_engine.pyc*10:53:01* > Removing basic-suite-master/test-scenarios/002_bootstrap.pyc*10:53:01* > Removing basic-suite-master/test-scenarios/003_00_metrics_bootstrap.pyc*10:53:01* > Removing basic-suite-master/test_utils/__init__.pyc*10:53:01* Removing > basic-suite-master/test_utils/constants.pyc*10:53:01* Removing > basic-suite-master/test_utils/network_utils_v4.pyc*10:53:01* Removing > exported-artifacts/*10:53:01* Removing mock_logs.LjHRcpGf/*10:53:01* > Removing mock_script_sid.x4jv1R*10:53:01* Removing > mocker-epel-7-x86_64.el7.cfg*10:53:01* *10:53:01* stderr: warning: > failed to remove .pki/*10:53:01* warning: failed to remove > deployment-basic-suite-master/default/uuid*10:53:01* warning: failed > to remove deployment-basic-suite-master/default/id_rsa > ... > -- > Didi -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-1873) Vdsm fcraw builds fail because ovirt-imageio-common is not installed
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1873?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-1873: ----------------------------- Resolution: Fixed Status: Done (was: To Do) > Vdsm fcraw builds fail because ovirt-imageio-common is not installed > -------------------------------------------------------------------- > > Key: OVIRT-1873 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1873 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Nir Soffer > Assignee: infra > > We require the package: > $ grep ovirt-imageio-common automation/check-patch.packages.fcraw > ovirt-imageio-common > Here are few failing builds, we have more: > http://jenkins.ovirt.org/job/vdsm_master_check-patch-fcraw-x86_64/95/consol… > http://jenkins.ovirt.org/job/vdsm_master_check-patch-fcraw-x86_64/97/consol… > http://jenkins.ovirt.org/job/vdsm_master_check-patch-fcraw-x86_64/96/consol… > *00:03:25.311* =================================== FAILURES > ===================================*00:03:25.311* > _________________________ test_import[vdsm.kvm2ovirt] > __________________________*00:03:25.312* *00:03:25.312* name = > 'vdsm.kvm2ovirt'*00:03:25.312* *00:03:25.312* > @pytest.mark.parametrize("name", find_modules())*00:03:25.312* def > test_import(name):*00:03:25.313* try:*00:03:25.313* > > importlib.import_module(name)*00:03:25.313* *00:03:25.313* > check_imports.py:61: *00:03:25.313* _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ *00:03:25.314* > /usr/lib64/python2.7/importlib/__init__.py:37: in > import_module*00:03:25.314* __import__(name)*00:03:25.314* _ _ _ _ > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ *00:03:25.315* *00:03:25.315* from __future__ import > absolute_import*00:03:25.315* *00:03:25.315* import > argparse*00:03:25.315* from contextlib import > contextmanager*00:03:25.315* import itertools*00:03:25.315* > import sys*00:03:25.316* import threading*00:03:25.316* > *00:03:25.316* > from ovirt_imageio_common import > directio*00:03:25.316* E ImportError: No module named > ovirt_imageio_common*00:03:25.316* *00:03:25.316* > ../lib/vdsm/kvm2ovirt.py:28: ImportError*00:03:25.317* ========== 1 > failed, 376 passed, 1 skipped, 1 xfailed in 3.25 seconds ========== -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-2023) mailing lists footer macros are broken
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2023?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-2023: ----------------------------- Resolution: Duplicate Status: Done (was: To Do) > mailing lists footer macros are broken > -------------------------------------- > > Key: OVIRT-2023 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2023 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Greg Sheremeta > Assignee: infra > Attachments: signature.asc > > > mailing lists footer macros are broken. Examples: > > Devel mailing list -- devel(a)ovirt.org > > To unsubscribe send an email to devel-leave(a)ovirt.org > > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > > > _______________________________________________ > Devel mailing list -- devel(a)ovirt.org > To unsubscribe send an email to devel-leave(a)ovirt.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > -- > GREG SHEREMETA > SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX > Red Hat NA > <https://www.redhat.com/> > gshereme(a)redhat.com IRC: gshereme > <https://red.ht/sig> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-1893) Remove ovirt-ansible-disaster-recovery-1.1 upstream version to install version 0.1 instead
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1893?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-1893: ----------------------------- Resolution: Fixed Status: Done (was: To Do) > Remove ovirt-ansible-disaster-recovery-1.1 upstream version to install version 0.1 instead > ------------------------------------------------------------------------------------------ > > Key: OVIRT-1893 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1893 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Maor Lipchuk > Assignee: infra > > Hi all, > It seems that ovirt-ansible-disaster-recovery repo installed from upstream > [1] is installed with version 1.1 [2]: > ovirt-ansible-disaster-recovery-1.1 is broken, because of a bug which was > already fixed [3] in ovirt-ansible-disaster-recovery 0.1. > The thing is that the release which automatically installed is 1.1 although > the fix is available in ovirt-ansible-disaster-recovery 0.1. > Is there a way to do something about it, could we remove the 1.1 versions, > so 0.1 will be installed instead? > [1] http://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm > [2] > ovirt-ansible-disaster-recovery-1.1.0-0.1.master.20180104150940.el7.centos.noarch > [3] https://github.com/oVirt/ovirt-ansible-disaster-recovery/pull/4 > Regards, > Maor -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-1271) GH plugin tries to consume gerrit's projects
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1271?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-1271: ----------------------------- Resolution: Fixed Status: Done (was: To Do) > GH plugin tries to consume gerrit's projects > -------------------------------------------- > > Key: OVIRT-1271 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1271 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Pavel Zhukov > Assignee: infra > Priority: Low > > Jenkins logs are flooded with: > Mar 23, 2017 10:40:05 AM com.cloudbees.jenkins.GitHubRepositoryName create > WARNING: Could not match URL http://gerrit.ovirt.org/jenkins.git > Mar 23, 2017 10:40:05 AM com.cloudbees.jenkins.GitHubRepositoryName create > WARNING: Could not match URL http://gerrit.ovirt.org/jenkins-whitelist.git > Mar 23, 2017 10:40:05 AM com.cloudbees.jenkins.GitHubRepositoryName create > WARNING: Could not match URL git://gerrit.ovirt.org/vdsm.git > Mar 23, 2017 10:40:05 AM com.cloudbees.jenkins.GitHubRepositoryName create > WARNING: Could not match URL http://gerrit.ovirt.org/jenkins.git > While the messages itself are harmless they floods the logs and consume jenkins master's resources. > See https://issues.jenkins-ci.org/browse/JENKINS-24422 for more details. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-1993) Looking for a new task to help with
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1993?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-1993: ----------------------------- Resolution: Done Status: Done (was: To Do) no reply from requestor > Looking for a new task to help with > ----------------------------------- > > Key: OVIRT-1993 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1993 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sailesh baskar > Assignee: infra > > I would like to open a new ticket in the infrastructure team. Can you help > in the process? -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-1973) vdsm_master_check-patch-fc27 fail due to yum repo issues
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1973?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-1973: ----------------------------- Resolution: Fixed Status: Done (was: To Do) > vdsm_master_check-patch-fc27 fail due to yum repo issues > -------------------------------------------------------- > > Key: OVIRT-1973 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1973 > Project: oVirt - virtualization made easy > Issue Type: Outage > Components: CI client projects > Reporter: danken > Assignee: infra > > Once in a while, jobs are failing due to > [MIRROR] kmod-kvdo-6.1.1.24-1.fc27.x86_64.rpm: Downloading successful, > but checksum doesn't match. Calculated: > 54996f8e7877b533bf43825853cd3c7cfd0f7df5cb6a1876e50c9ade7829dd73(sha256) > Expected: 7a8294588764bd2c14adaa7d24218cce344930c1ce62a24b17208d1cd629c461(sha256) > for example > http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-x86_64/2830/conso… -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-1971) oVirt Bugzilla automation: Bugs didn't move to ON_QA [Bug 1542087]
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1971?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-1971: ----------------------------- Resolution: Cannot Reproduce Status: Done (was: To Do) > oVirt Bugzilla automation: Bugs didn't move to ON_QA [Bug 1542087] > ------------------------------------------------------------------ > > Key: OVIRT-1971 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1971 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Components: Bugzilla Automation > Reporter: Eyal Edri > Assignee: Anton Marchukov > Labels: bugzilla, > > Sending to infra-support to track this as a ticket. > On Fri, Apr 13, 2018 at 3:35 PM, Anton Marchukov <amarchuk(a)redhat.com> > wrote: > > Hello Greg. > > > > Thanks. > > > > Anton. > > > > > > On 13 April 2018 at 14:27:26, Greg Sheremeta (gshereme(a)redhat.com) wrote: > > > Thanks. I moved the rest (we had 3) > > > > > > On Fri, Apr 13, 2018 at 8:24 AM, Anton Marchukov > > > wrote: > > > > > > > Hello Greg. > > > > > > > > You are right and the patch is included in the tag. Sounds like there > > > > are some problems with detecting earlier changes. I moved to ON_QA > > > > manually while we check this. > > > > > > > > Anton. > > > > > > > > > > > > On 13 April 2018 at 14:16:30, Greg Sheremeta (gshereme(a)redhat.com) > > wrote: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1542087 > > > > > > > > > > > > > > > > -- > > > > > > GREG SHEREMETA > > > > > > SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX > > > > > > Red Hat NA > > > > > > > > > > > > gshereme(a)redhat.com IRC: gshereme > > > > > > > > _______________________________________________ > > 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#100095)

1 0

[JIRA] (OVIRT-2095) Re: he-basic-ansible_suite_master: failed to set MSR 0xd90 to 0x0
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2095?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-2095: ----------------------------- Resolution: Cannot Reproduce Status: Done (was: To Do) > Re: he-basic-ansible_suite_master: failed to set MSR 0xd90 to 0x0 > ----------------------------------------------------------------- > > Key: OVIRT-2095 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2095 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: OST > Reporter: Eyal Edri > Assignee: Gal Ben Haim > > Opening a ticket on it, Gal will look into it, it might take some time to > investigate. > On Mon, Mar 26, 2018 at 1:24 PM, Yedidyah Bar David <didi(a)redhat.com> wrote: > > Hi all, > > > > Trying to run ovirt-system-tests using mock_runner.sh on my laptop > > (i7-6820HQ T460p, RHEL 7.4, kernel 3.10.0-693.17.1.el7.x86_64, > > qemu-kvm-rhev-2.9.0-16.el7_4.13.x86_64). > > > > hosted-engine deploy starts, and fails while running virt-install to > > create the engine vm (which will be a nested-kvm vm). > > > > qemu log on the nested-kvm host0 says: > > > > 2018-03-26T08:02:16.727212Z qemu-kvm: error: failed to set MSR 0xd90 to 0x0 > > qemu-kvm: /builddir/build/BUILD/qemu-2.9.0/target/i386/kvm.c:1843: > > kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. > > > > Searched and found this: > > > > https://bugs.launchpad.net/qemu/+bug/1665389 > > > > which seems very similar, although from a year ago and about a fedora > > 24 kernel+qemu. The conclusion there is: > > > > <quote> > > Yes, I mean '-cpu host' in the bare metal. There is no workaround; it > > worked by chance and it triggered other hard to find bugs. > > </quote> > > > > So, what should I/we do? Is there a workaround? How does this work > > elsewhere? > > > > Thanks, > > -- > > Didi > > _______________________________________________ > > 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#100095)

1 0

[JIRA] (OVIRT-1957) [VDSM] check-merge lago VM does not respond.
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1957?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-1957: ----------------------------- Resolution: Won't Fix Status: Done (was: To Do) check-merged jobs were removed as part of moving toV2 > [VDSM] check-merge lago VM does not respond. > -------------------------------------------- > > Key: OVIRT-1957 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1957 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Edward Haas > Assignee: infra > > Hello, > Seems like from time to time, VDSM master check-merge, which raises a Lago > VM to run the functional tests is failing. > Based on the logs, we seem to loose the VM (please re-check me on this) > with no apparent reason. The tests that run at the time this is happening > just check the VDSM API validation, they are not even touching the > configuration. > Could you please try to help us with this issue? > Thanks, > Edy. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-1683) Add a type key to the list of available upstream sources
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1683?page=com.atlassian.jira.… ] Eyal Edri commented on OVIRT-1683: ---------------------------------- [~bkorren(a)redhat.com] do you think we still need it? I suggest to close it and handle only if a requirement from users / project will arise. > Add a type key to the list of available upstream sources > -------------------------------------------------------- > > Key: OVIRT-1683 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1683 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: usrc.py > Reporter: Gil Shinar > Assignee: infra > > Currently, code supports the following upstream_sources.yaml file: > git: > - url: <git url> > commit: <git commit> > branch: <branch name> > and we need to support: > - type: git > url: <git url> > commit: <git commit> > branch: <branch name> > - type: svn > url: <svn url> > commit: <svn revision> > branch: <branch name> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-1498) Gate lago versions with change-queue
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1498?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-1498: ----------------------------- Resolution: Won't Fix Status: Done (was: To Do) Lago releases are not happening that often and history shows they didn't really cause regressions, don't see a need to implement this, so closing. we'll revisit in the future if needed. > Gate lago versions with change-queue > ------------------------------------ > > Key: OVIRT-1498 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1498 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Change Queue, Lago > Reporter: Barak Korren > Assignee: infra > Priority: High > Labels: change-queue, gating, lago, ost > > Lago should be considered an upstream dependency, like CentOS and libvirt. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-1318) configure backup of status.ovirt.org
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1318?page=com.atlassian.jira.… ] Eyal Edri commented on OVIRT-1318: ---------------------------------- [~ederevea] where do we host status.ovirt.org now? do we still need it? > configure backup of status.ovirt.org > ------------------------------------ > > Key: OVIRT-1318 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1318 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Evgheni Dereveanchin > Assignee: infra > Priority: Low > > status.ovirt.org was set up - need to investigate if it needs to be backed up or we can produce documentation to set up a new stats page in case something happens to the existing OpenShift gear. > We can use OpenShift's built in backup/restore functionality: > https://developers.openshift.com/managing-your-applications/backing-up-appl… -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0

[JIRA] (OVIRT-1290) Re-factor OST jobs YAML to reduce duplication
by Eyal Edri (oVirt JIRA) 15 Dec '18

15 Dec '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1290?page=com.atlassian.jira.… ] Eyal Edri updated OVIRT-1290: ----------------------------- Resolution: Fixed Status: Done (was: To Do) AFAIK, all suites use the same YAML file now, and in any case, not something worth investing time in. > Re-factor OST jobs YAML to reduce duplication > --------------------------------------------- > > Key: OVIRT-1290 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1290 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: OST Manual job, OST scheduled jobs > Reporter: Barak Korren > Assignee: infra > Labels: ost, yaml > > Besides the experimental flow jobs, and the manual OST job, we also have a few more jobs that run specific OST suits on a scheduled basis. > Historically theses suits were written by different people and different job templates in YAML were also written for each suit. > At some point we have normalized all the suit names in OST to be of the following structure: > {code} > <suit_type>-suit-<ovirt version> > {code} > This was initially done to allow the mirror injection process to find the '{{reposync-config.repo}}' file but also facilitated the creation of the generic manual OST job. > Since all suites now follow the same naming convention there is no more reason to have separate YAML job templates per suit. This separation may even cause subtle issues. > All the YAML OST job templates should be unified so that we'll have just one job template that is parametrized by the suite type and oVirt version. Furthermore we can probably have just one YAML project entry to create all scheduled OST jobs. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095)

1 0