October 2019 - Infra - oVirt List Archives

[CQ]: 104168,3 (jenkins) failed "dummy-master" system tests
by oVirt Jenkins 22 Oct '19

22 Oct '19

Change 104168,3 (jenkins) is probably the reason behind recent system test failures in the "dummy-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/104168/3 For failed test results see: http://jenkins.ovirt.org/job/dummy-master_change-queue-tester/121/

1 0

[oVirt Jenkins] deploy-to-gated-dummy-master - Build #66 - FAILURE!
by jenkins＠jenkins.phx.ovirt.org 22 Oct '19

22 Oct '19

Build: http://jenkins.ovirt.org/job/deploy-to-gated-dummy-master/66/ Build Name: #66 Build Status: FAILURE Gerrit change: null - title: null - project: null - branch: null - author: null <null>

1 0

[CQ]: 104079,4 (vdsm) failed "ovirt-master" system tests
by oVirt Jenkins 22 Oct '19

22 Oct '19

Change 104079,4 (vdsm) 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/104079/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/16609/

1 0

[JIRA] (OVIRT-2814) reposync fails syncing repos on completely unrelated paths (concurrency issue?)
by Barak Korren (oVirt JIRA) 22 Oct '19

22 Oct '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2814?page=com.atlassian.jira.… ] Barak Korren edited comment on OVIRT-2814 at 10/22/19 1:54 PM: --------------------------------------------------------------- {quote} correct me if I’m worng but no real fix has been included right? lock file has just been removed and we’re going to see this happen again sooner or later. {quote} Ok, I see what you talk about now, I missed the fact that the failure was in a job for a different mirror. To solve this, we need to make sure that when we sync repo X, the {{reposync}} command only sees the part of "{{mirrors-reposync.conf}}" that is relevant for repo X. It should probably be doable by adding a {{sed}} command to {{mirror_mgr.sh}} that will remove the unneeded repos from the file before running {{reposync}}. [~accountid:5b25ec3f8b08c009c48b25c9] this is exactly what we've talked about before you left today... was (Author: bkorren(a)redhat.com) {quote} correct me if I’m worng but no real fix has been included right? lock file has just been removed and we’re going to see this happen again sooner or later. {quote} Ok, I see whay you talk about now, I missed the fact that the failure was in a job for a different mirror. To solve this, we need to make sure that when we sync repo X, the {{reposync}} command only sees the part of "{{mirrors-reposync.conf}}" that is relevant for repo X. It should probably be doable by adding a {{sed}} command to {{mirror_mgr.sh}} that will remove the unneeded repos from the file before running {{reposync}}. [~accountid:5b25ec3f8b08c009c48b25c9] this is exactly what we've talked about before you left today... > reposync fails syncing repos on completely unrelated paths (concurrency issue?) > ------------------------------------------------------------------------------- > > Key: OVIRT-2814 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2814 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Components: CI Mirrors > Reporter: Sandro Bonazzola > Assignee: infra > > About job > https://jenkins.ovirt.org/job/system-sync_mirrors-centos-kvm-common-el7-x86… > As you can see below > 05:35:07 ++ reposync --config=jenkins/data/mirrors-reposync.conf > --repoid=centos-kvm-common-el7 --arch=x86_64 > --cachedir=/home/jenkins/mirrors_cache > --download_path=/var/www/html/repos/yum/centos-kvm-common-el7/base > --norepopath --newest-only --urls --quiet > the sync is related to "/var/www/html/repos/yum/centos-kvm-common-el7/base" > using as cache directory "/home/jenkins/mirrors_cache" > but in "/home/jenkins/mirrors_cache" there's > "/home/jenkins/mirrors_cache/fedora-base-fc29": > 05:35:16 Traceback (most recent call last): > 05:35:16 File "/usr/bin/reposync", line 373, in <module> > 05:35:16 main() > 05:35:16 File "/usr/bin/reposync", line 185, in main > 05:35:16 my.doRepoSetup() > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/__init__.py", line > 681, in doRepoSetup > 05:35:16 return self._getRepos(thisrepo, True) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/__init__.py", line > 721, in _getRepos > 05:35:16 self._repos.doSetup(thisrepo) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, > in doSetup > 05:35:16 self.retrieveAllMD() > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/repos.py", line 88, > in retrieveAllMD > 05:35:16 dl = repo._async and repo._commonLoadRepoXML(repo) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 1468, in _commonLoadRepoXML > 05:35:16 local = self.cachedir + '/repomd.xml' > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 777, in <lambda> > 05:35:16 cachedir = property(lambda self: self._dirGetAttr('cachedir')) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 760, in _dirGetAttr > 05:35:16 self.dirSetup() > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 738, in dirSetup > 05:35:16 self._dirSetupMkdir_p(dir) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 715, in _dirSetupMkdir_p > 05:35:16 raise Errors.RepoError, msg > 05:35:16 yum.Errors.RepoError: Error making cache directory: > /home/jenkins/mirrors_cache/fedora-base-fc29 error was: [Errno 17] File > exists: '/home/jenkins/mirrors_cache/fedora-base-fc29' > this looks like a concurrency issue, a lock should be used in order to > prevent two instances to use the same cache directory at the same time or > use separate cache directories for different repos. > -- > Sandro Bonazzola -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100114)

1 0

[JIRA] (OVIRT-2814) reposync fails syncing repos on completely unrelated paths (concurrency issue?)
by Barak Korren (oVirt JIRA) 22 Oct '19

22 Oct '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2814?page=com.atlassian.jira.… ] Barak Korren reopened OVIRT-2814: --------------------------------- > reposync fails syncing repos on completely unrelated paths (concurrency issue?) > ------------------------------------------------------------------------------- > > Key: OVIRT-2814 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2814 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Components: CI Mirrors > Reporter: Sandro Bonazzola > Assignee: infra > > About job > https://jenkins.ovirt.org/job/system-sync_mirrors-centos-kvm-common-el7-x86… > As you can see below > 05:35:07 ++ reposync --config=jenkins/data/mirrors-reposync.conf > --repoid=centos-kvm-common-el7 --arch=x86_64 > --cachedir=/home/jenkins/mirrors_cache > --download_path=/var/www/html/repos/yum/centos-kvm-common-el7/base > --norepopath --newest-only --urls --quiet > the sync is related to "/var/www/html/repos/yum/centos-kvm-common-el7/base" > using as cache directory "/home/jenkins/mirrors_cache" > but in "/home/jenkins/mirrors_cache" there's > "/home/jenkins/mirrors_cache/fedora-base-fc29": > 05:35:16 Traceback (most recent call last): > 05:35:16 File "/usr/bin/reposync", line 373, in <module> > 05:35:16 main() > 05:35:16 File "/usr/bin/reposync", line 185, in main > 05:35:16 my.doRepoSetup() > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/__init__.py", line > 681, in doRepoSetup > 05:35:16 return self._getRepos(thisrepo, True) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/__init__.py", line > 721, in _getRepos > 05:35:16 self._repos.doSetup(thisrepo) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, > in doSetup > 05:35:16 self.retrieveAllMD() > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/repos.py", line 88, > in retrieveAllMD > 05:35:16 dl = repo._async and repo._commonLoadRepoXML(repo) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 1468, in _commonLoadRepoXML > 05:35:16 local = self.cachedir + '/repomd.xml' > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 777, in <lambda> > 05:35:16 cachedir = property(lambda self: self._dirGetAttr('cachedir')) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 760, in _dirGetAttr > 05:35:16 self.dirSetup() > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 738, in dirSetup > 05:35:16 self._dirSetupMkdir_p(dir) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 715, in _dirSetupMkdir_p > 05:35:16 raise Errors.RepoError, msg > 05:35:16 yum.Errors.RepoError: Error making cache directory: > /home/jenkins/mirrors_cache/fedora-base-fc29 error was: [Errno 17] File > exists: '/home/jenkins/mirrors_cache/fedora-base-fc29' > this looks like a concurrency issue, a lock should be used in order to > prevent two instances to use the same cache directory at the same time or > use separate cache directories for different repos. > -- > Sandro Bonazzola -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100114)

1 0

[JIRA] (OVIRT-2814) reposync fails syncing repos on completely unrelated paths (concurrency issue?)
by Barak Korren (oVirt JIRA) 22 Oct '19

22 Oct '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2814?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-2814: -------------------------------- Components: CI Mirrors > reposync fails syncing repos on completely unrelated paths (concurrency issue?) > ------------------------------------------------------------------------------- > > Key: OVIRT-2814 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2814 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Components: CI Mirrors > Reporter: Sandro Bonazzola > Assignee: infra > > About job > https://jenkins.ovirt.org/job/system-sync_mirrors-centos-kvm-common-el7-x86… > As you can see below > 05:35:07 ++ reposync --config=jenkins/data/mirrors-reposync.conf > --repoid=centos-kvm-common-el7 --arch=x86_64 > --cachedir=/home/jenkins/mirrors_cache > --download_path=/var/www/html/repos/yum/centos-kvm-common-el7/base > --norepopath --newest-only --urls --quiet > the sync is related to "/var/www/html/repos/yum/centos-kvm-common-el7/base" > using as cache directory "/home/jenkins/mirrors_cache" > but in "/home/jenkins/mirrors_cache" there's > "/home/jenkins/mirrors_cache/fedora-base-fc29": > 05:35:16 Traceback (most recent call last): > 05:35:16 File "/usr/bin/reposync", line 373, in <module> > 05:35:16 main() > 05:35:16 File "/usr/bin/reposync", line 185, in main > 05:35:16 my.doRepoSetup() > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/__init__.py", line > 681, in doRepoSetup > 05:35:16 return self._getRepos(thisrepo, True) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/__init__.py", line > 721, in _getRepos > 05:35:16 self._repos.doSetup(thisrepo) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, > in doSetup > 05:35:16 self.retrieveAllMD() > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/repos.py", line 88, > in retrieveAllMD > 05:35:16 dl = repo._async and repo._commonLoadRepoXML(repo) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 1468, in _commonLoadRepoXML > 05:35:16 local = self.cachedir + '/repomd.xml' > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 777, in <lambda> > 05:35:16 cachedir = property(lambda self: self._dirGetAttr('cachedir')) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 760, in _dirGetAttr > 05:35:16 self.dirSetup() > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 738, in dirSetup > 05:35:16 self._dirSetupMkdir_p(dir) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 715, in _dirSetupMkdir_p > 05:35:16 raise Errors.RepoError, msg > 05:35:16 yum.Errors.RepoError: Error making cache directory: > /home/jenkins/mirrors_cache/fedora-base-fc29 error was: [Errno 17] File > exists: '/home/jenkins/mirrors_cache/fedora-base-fc29' > this looks like a concurrency issue, a lock should be used in order to > prevent two instances to use the same cache directory at the same time or > use separate cache directories for different repos. > -- > Sandro Bonazzola -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100114)

1 0

[JIRA] (OVIRT-2814) reposync fails syncing repos on completely unrelated paths (concurrency issue?)
by Barak Korren (oVirt JIRA) 22 Oct '19

22 Oct '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2814?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-2814: ------------------------------------- {quote} correct me if I’m worng but no real fix has been included right? lock file has just been removed and we’re going to see this happen again sooner or later. {quote} Ok, I see whay you talk about now, I missed the fact that the failure was in a job for a different mirror. To solve this, we need to make sure that when we sync repo X, the {{reposync}} command only sees the part of "{{mirrors-reposync.conf}}" that is relevant for repo X. It should probably be doable by adding a {{sed}} command to {{mirror_mgr.sh}} that will remove the unneeded repos from the file before running {{reposync}}. [~accountid:5b25ec3f8b08c009c48b25c9] this is exactly what we've talked about before you left today... > reposync fails syncing repos on completely unrelated paths (concurrency issue?) > ------------------------------------------------------------------------------- > > Key: OVIRT-2814 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2814 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Sandro Bonazzola > Assignee: infra > > About job > https://jenkins.ovirt.org/job/system-sync_mirrors-centos-kvm-common-el7-x86… > As you can see below > 05:35:07 ++ reposync --config=jenkins/data/mirrors-reposync.conf > --repoid=centos-kvm-common-el7 --arch=x86_64 > --cachedir=/home/jenkins/mirrors_cache > --download_path=/var/www/html/repos/yum/centos-kvm-common-el7/base > --norepopath --newest-only --urls --quiet > the sync is related to "/var/www/html/repos/yum/centos-kvm-common-el7/base" > using as cache directory "/home/jenkins/mirrors_cache" > but in "/home/jenkins/mirrors_cache" there's > "/home/jenkins/mirrors_cache/fedora-base-fc29": > 05:35:16 Traceback (most recent call last): > 05:35:16 File "/usr/bin/reposync", line 373, in <module> > 05:35:16 main() > 05:35:16 File "/usr/bin/reposync", line 185, in main > 05:35:16 my.doRepoSetup() > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/__init__.py", line > 681, in doRepoSetup > 05:35:16 return self._getRepos(thisrepo, True) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/__init__.py", line > 721, in _getRepos > 05:35:16 self._repos.doSetup(thisrepo) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, > in doSetup > 05:35:16 self.retrieveAllMD() > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/repos.py", line 88, > in retrieveAllMD > 05:35:16 dl = repo._async and repo._commonLoadRepoXML(repo) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 1468, in _commonLoadRepoXML > 05:35:16 local = self.cachedir + '/repomd.xml' > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 777, in <lambda> > 05:35:16 cachedir = property(lambda self: self._dirGetAttr('cachedir')) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 760, in _dirGetAttr > 05:35:16 self.dirSetup() > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 738, in dirSetup > 05:35:16 self._dirSetupMkdir_p(dir) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 715, in _dirSetupMkdir_p > 05:35:16 raise Errors.RepoError, msg > 05:35:16 yum.Errors.RepoError: Error making cache directory: > /home/jenkins/mirrors_cache/fedora-base-fc29 error was: [Errno 17] File > exists: '/home/jenkins/mirrors_cache/fedora-base-fc29' > this looks like a concurrency issue, a lock should be used in order to > prevent two instances to use the same cache directory at the same time or > use separate cache directories for different repos. > -- > Sandro Bonazzola -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100114)

1 0

[CQ]: 1669fb3 (ovirt-ansible-infra) failed "ovirt-4.3" system tests, but isn't the failure root cause
by oVirt Jenkins 22 Oct '19

22 Oct '19

A system test invoked by the "ovirt-4.3" change queue including change 1669fb3 (ovirt-ansible-infra) failed. However, this change seems not to be the root cause for this failure. Change 4d1c40f (ovirt-ansible-infra) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 4d1c40f (ovirt-ansible-infra) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://github.com/oVirt/ovirt-ansible-infra/commit/1669fb329f626d29086c36f… For further details about the change that seems to be the root cause behind the testing failures see: https://github.com/oVirt/ovirt-ansible-infra/commit/4d1c40ffb2c62b8b60c8f7b… For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.3_change-queue-tester/2319/

1 0

[JIRA] (OVIRT-2814) reposync fails syncing repos on completely unrelated paths (concurrency issue?)
by Sandro Bonazzola (oVirt JIRA) 22 Oct '19

22 Oct '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2814?page=com.atlassian.jira.… ] Sandro Bonazzola commented on OVIRT-2814: ----------------------------------------- correct me if I’m worng but no real fix has been included right? lock file has just been removed and we’re going to see this happen again sooner or later. > reposync fails syncing repos on completely unrelated paths (concurrency issue?) > ------------------------------------------------------------------------------- > > Key: OVIRT-2814 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2814 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Sandro Bonazzola > Assignee: infra > > About job > https://jenkins.ovirt.org/job/system-sync_mirrors-centos-kvm-common-el7-x86… > As you can see below > 05:35:07 ++ reposync --config=jenkins/data/mirrors-reposync.conf > --repoid=centos-kvm-common-el7 --arch=x86_64 > --cachedir=/home/jenkins/mirrors_cache > --download_path=/var/www/html/repos/yum/centos-kvm-common-el7/base > --norepopath --newest-only --urls --quiet > the sync is related to "/var/www/html/repos/yum/centos-kvm-common-el7/base" > using as cache directory "/home/jenkins/mirrors_cache" > but in "/home/jenkins/mirrors_cache" there's > "/home/jenkins/mirrors_cache/fedora-base-fc29": > 05:35:16 Traceback (most recent call last): > 05:35:16 File "/usr/bin/reposync", line 373, in <module> > 05:35:16 main() > 05:35:16 File "/usr/bin/reposync", line 185, in main > 05:35:16 my.doRepoSetup() > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/__init__.py", line > 681, in doRepoSetup > 05:35:16 return self._getRepos(thisrepo, True) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/__init__.py", line > 721, in _getRepos > 05:35:16 self._repos.doSetup(thisrepo) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, > in doSetup > 05:35:16 self.retrieveAllMD() > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/repos.py", line 88, > in retrieveAllMD > 05:35:16 dl = repo._async and repo._commonLoadRepoXML(repo) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 1468, in _commonLoadRepoXML > 05:35:16 local = self.cachedir + '/repomd.xml' > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 777, in <lambda> > 05:35:16 cachedir = property(lambda self: self._dirGetAttr('cachedir')) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 760, in _dirGetAttr > 05:35:16 self.dirSetup() > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 738, in dirSetup > 05:35:16 self._dirSetupMkdir_p(dir) > 05:35:16 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line > 715, in _dirSetupMkdir_p > 05:35:16 raise Errors.RepoError, msg > 05:35:16 yum.Errors.RepoError: Error making cache directory: > /home/jenkins/mirrors_cache/fedora-base-fc29 error was: [Errno 17] File > exists: '/home/jenkins/mirrors_cache/fedora-base-fc29' > this looks like a concurrency issue, a lock should be used in order to > prevent two instances to use the same cache directory at the same time or > use separate cache directories for different repos. > -- > Sandro Bonazzola -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100114)

1 0

[JIRA] (OVIRT-2813) EL8 builds fail to mount loop device - kernel too old?
by Anton Marchukov (oVirt JIRA) 22 Oct '19

22 Oct '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2813?page=com.atlassian.jira.… ] Anton Marchukov reassigned OVIRT-2813: -------------------------------------- Assignee: Barak Korren (was: infra) > EL8 builds fail to mount loop device - kernel too old? > ------------------------------------------------------ > > Key: OVIRT-2813 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2813 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Nir Soffer > Assignee: Barak Korren > > I'm trying to run imageio tests on el8 mock, and the tests fail early when > trying to create storage > for testing: > [userstorage] INFO Creating filesystem > /var/tmp/imageio-storage/file-512-ext4-mount > Suggestion: Use Linux kernel >= 3.18 for improved stability of the > metadata and journal checksum features. > [userstorage] INFO Creating file > /var/tmp/imageio-storage/file-512-ext4-mount/file > [userstorage] INFO Creating backing file > /var/tmp/imageio-storage/file-512-xfs-backing > [userstorage] INFO Creating loop device > /var/tmp/imageio-storage/file-512-xfs-loop > [userstorage] INFO Creating filesystem > /var/tmp/imageio-storage/file-512-xfs-mount > mount: /var/tmp/imageio-storage/file-512-xfs-mount: wrong fs type, bad > option, bad superblock on /dev/loop4, missing codepage or helper > program, or other error. > Traceback (most recent call last): > File "/usr/local/bin/userstorage", line 10, in <module> > sys.exit(main()) > File "/usr/local/lib/python3.6/site-packages/userstorage/__main__.py", > line 42, in main > create(cfg) > File "/usr/local/lib/python3.6/site-packages/userstorage/__main__.py", > line 52, in create > b.create() > File "/usr/local/lib/python3.6/site-packages/userstorage/file.py", > line 47, in create > self._mount.create() > File "/usr/local/lib/python3.6/site-packages/userstorage/mount.py", > line 53, in create > self._mount_loop() > File "/usr/local/lib/python3.6/site-packages/userstorage/mount.py", > line 94, in _mount_loop > ["sudo", "mount", "-t", self.fstype, self._loop.path, self.path]) > File "/usr/lib64/python3.6/subprocess.py", line 311, in check_call > raise CalledProcessError(retcode, cmd) > subprocess.CalledProcessError: Command '['sudo', 'mount', '-t', 'xfs', > '/var/tmp/imageio-storage/file-512-xfs-loop', > '/var/tmp/imageio-storage/file-512-xfs-mount']' returned non-zero exit > status 32. > https://jenkins.ovirt.org/job/ovirt-imageio_standard-check-patch/1593//arti… > Same code runs fine in Travis: > https://travis-ci.org/nirs/ovirt-imageio/jobs/595794863 > And also locally on Fedora 29: > $ ../jenkins/mock_configs/mock_runner.sh -C ../jenkins/mock_configs -p el8 > ... > ## Wed Oct 9 23:37:22 IDT 2019 Finished env: el8:epel-8-x86_64 > ## took 85 seconds > ## rc = 0 > My guess is that we run el8 jobs on el7 hosts with old kernels > (Suggestion: Use Linux kernel >= 3.18 for improved stability of the > metadata and journal checksum features.) > This issue will affects vdsm, using similar code to create storage for > testing. > For vdsm the issue is more tricky, since it requires same host/distro: > 49 - tests-py37: > 50 runtime-requirements: > 51 host-distro: same > So I think we need: > - make slaves with newer kernel (fc29? fc30?) with the el8 mock env > - add el8 slaves for running el8 mock with "host-distro: same" > If we don't have a solution we need to disable el8 tests, or continue > testing without > storage, which will skip about 200 tests. > Nir -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100114)

1 0