July 2021 - Devel - oVirt List Archives

test_cold_incremental_backup_vm2: "Cannot backup VM. The VM is during a backup operation"
by Yedidyah Bar David 08 Jul '21

08 Jul '21

On Sun, Jul 4, 2021 at 8:26 AM <jenkins(a)jenkins.phx.ovirt.org> wrote: > > Project: https://jenkins.ovirt.org/job/ovirt-system-tests_basic-suite-master_nightly/ > Build: https://jenkins.ovirt.org/job/ovirt-system-tests_basic-suite-master_nightly… > Build Number: 1291 > Build Status: Failure > Triggered By: Started by timer > > ------------------------------------- > Changes Since Last Success: > ------------------------------------- > Changes for Build #1291 > [Marcin Sobczyk] network: Add missing 'ansible_hosts' fixture > > > > > ----------------- > Failed Tests: > ----------------- > 1 tests failed. > FAILED: basic-suite-master.test-scenarios.test_004_basic_sanity.test_cold_incremental_backup_vm2 > > Error Message: > ovirtsdk4.Error: Fault reason is "Operation Failed". Fault detail is "[Cannot backup VM. The VM is during a backup operation.]". HTTP response code is 409. Something similar now happened to me too: https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/17729/ https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/17729… This job triggered also he-basic, which passed. basic failed as in here. Any idea? Best regards, > > Stack Trace: > engine_api = <ovirtsdk4.Connection object at 0x7f1f943c3208> > get_vm_service_for_vm = <function get_vm_service_for_vm.<locals>.service_for at 0x7f1f944e1268> > > @order_by(_TEST_LIST) > def test_cold_incremental_backup_vm2(engine_api, get_vm_service_for_vm): > _verify_vm_state(engine_api.system_service(), VM2_NAME, types.VmStatus.DOWN) > vm2_backups_service = get_vm_service_for_vm(VM2_NAME).backups_service() > backup.perform_incremental_vm_backup( > > engine_api, vm2_backups_service, DISK2_NAME, "cold_vm_backup") > > basic-suite-master/test-scenarios/test_004_basic_sanity.py:1056: > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > ost_utils/ost_utils/storage_utils/backup.py:75: in perform_incremental_vm_backup > correlation_id="incremental_" + correlation_id) > ost_utils/ost_utils/storage_utils/backup.py:34: in perform_vm_backup > ), query={'correlation_id': correlation_id} > /usr/lib64/python3.6/site-packages/ovirtsdk4/services.py:34139: in add > return self._internal_add(backup, headers, query, wait) > /usr/lib64/python3.6/site-packages/ovirtsdk4/service.py:232: in _internal_add > return future.wait() if wait else future > /usr/lib64/python3.6/site-packages/ovirtsdk4/service.py:55: in wait > return self._code(response) > /usr/lib64/python3.6/site-packages/ovirtsdk4/service.py:229: in callback > self._check_fault(response) > /usr/lib64/python3.6/site-packages/ovirtsdk4/service.py:132: in _check_fault > self._raise_error(response, body) > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > response = <ovirtsdk4.http.Response object at 0x7f1f94399c50> > detail = <ovirtsdk4.types.Fault object at 0x7f1f94399f60> > > @staticmethod > def _raise_error(response, detail=None): > """ > Creates and raises an error containing the details of the given HTTP > response and fault. > > This method is intended for internal use by other components of the > SDK. Refrain from using it directly, as backwards compatibility isn't > guaranteed. > """ > fault = detail if isinstance(detail, types.Fault) else None > > msg = '' > if fault: > if fault.reason: > if msg: > msg += ' ' > msg = msg + 'Fault reason is "%s".' % fault.reason > if fault.detail: > if msg: > msg += ' ' > msg = msg + 'Fault detail is "%s".' % fault.detail > if response: > if response.code: > if msg: > msg += ' ' > msg = msg + 'HTTP response code is %s.' % response.code > if response.message: > if msg: > msg += ' ' > msg = msg + 'HTTP response message is "%s".' % response.message > > if isinstance(detail, six.string_types): > if msg: > msg += ' ' > msg = msg + detail + '.' > > class_ = Error > if response is not None: > if response.code in [401, 403]: > class_ = AuthError > elif response.code == 404: > class_ = NotFoundError > > error = class_(msg) > error.code = response.code if response else None > error.fault = fault > > raise error > E ovirtsdk4.Error: Fault reason is "Operation Failed". Fault detail is "[Cannot backup VM. The VM is during a backup operation.]". HTTP response code is 409. > > /usr/lib64/python3.6/site-packages/ovirtsdk4/service.py:118: Error_______________________________________________ > Infra mailing list -- infra(a)ovirt.org > To unsubscribe send an email to infra-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/privacy-policy.html > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/PCZSYD7BHWGVM… -- Didi

4 3

importing fixtures in ovirt-system-tests
by Yedidyah Bar David 08 Jul '21

08 Jul '21

Hi all, We have several different styles of where/how to import fixtures in ovirt-system-tests: - import directly inside the test code - import in conftest.py - import in fixtures modules - For all of above, both 'import *' and importing specific fixtures I think we should try to agree on a specific style and then follow it. One drawback of importing directly in test/fixtures code is that it's then impossible to override them in conftest.py. A drawback of importing '*' and/or doing this in conftest.py is that you might inadvertently import more than you want, or this might happen eventually (after more stuff are added), that this makes it harder to find what uses what, and that it risks unintended collisions in names - as opposed to intended overrides. A related issue is having to update many places if you add/change something. If there is some kind of "best practices" document somewhere that people are happy with, perhaps we should follow it. Otherwise, we should come up with our own. Personally I think I'd like to have a single file with all the imports, of specific fixtures (not '*'), and import this file from conftest.py of all the suites. Didn't actually try this and no idea what complications it might bring. Comments/ideas/opinions/decisions are welcome :-) Best regards, -- Didi

3 2

ppc64le mock environment is broken
by Sandro Bonazzola 07 Jul '21

07 Jul '21

Looking at https://jenkins.ovirt.org/blue/organizations/jenkins/ovirt-release_standard… It shows: # /usr/bin/yum --installroot /var/lib/mock/centos-stream-8-ppc64le-6cf77c626743751e199a195f6b050912-bootstrap-10125/root/ --releasever 8 install dnf dnf-plugins-core --setopt=tsflags=nocontexts command being executed and failing with: [2021-07-07T15:18:32.577Z] --> Finished Dependency Resolution [2021-07-07T15:18:32.577Z] Error: Package: python3-dnf-4.7.0-1.el8.noarch (centos-base-el8stream) [2021-07-07T15:18:32.577Z] Requires: python(abi) = 3.6 [2021-07-07T15:18:32.577Z] Error: Package: python3-dnf-4.7.0-1.el8.noarch (centos-base-el8stream) [2021-07-07T15:18:32.577Z] Requires: python3-libdnf >= 0.61.1 [2021-07-07T15:18:32.577Z] Error: Package: 1:python3-dateutil-2.6.1-6.el8.noarch (centos-base-el8stream) [2021-07-07T15:18:32.577Z] Requires: python(abi) = 3.6 [2021-07-07T15:18:32.577Z] Error: Package: python3-dnf-plugins-core-4.0.21-1.el8.noarch (centos-base-el8stream) [2021-07-07T15:18:32.577Z] Requires: python3-dbus [2021-07-07T15:18:32.577Z] Error: Package: python3-dnf-4.7.0-1.el8.noarch (centos-base-el8stream) [2021-07-07T15:18:32.577Z] Requires: python3-libcomps >= 0.1.8 [2021-07-07T15:18:32.577Z] Error: Package: dnf-data-4.7.0-1.el8.noarch (centos-base-el8stream) [2021-07-07T15:18:32.577Z] Requires: libreport-filesystem [2021-07-07T15:18:32.577Z] Error: Package: python3-dnf-4.7.0-1.el8.noarch (centos-base-el8stream) [2021-07-07T15:18:32.577Z] Requires: libmodulemd >= 2.9.3 [2021-07-07T15:18:32.577Z] Error: Package: python3-dnf-plugins-core-4.0.21-1.el8.noarch (centos-base-el8stream) [2021-07-07T15:18:32.577Z] Requires: python(abi) = 3.6 [2021-07-07T15:18:32.577Z] Error: Package: python3-dnf-plugins-core-4.0.21-1.el8.noarch (centos-base-el8stream) [2021-07-07T15:18:32.577Z] Requires: python3-hawkey >= 0.46.1 [2021-07-07T15:18:32.577Z] Error: Package: dnf-4.7.0-1.el8.noarch (centos-base-el8stream) [2021-07-07T15:18:32.577Z] Requires: /bin/sh [2021-07-07T15:18:32.577Z] Error: Package: python3-dnf-4.7.0-1.el8.noarch (centos-base-el8stream) [2021-07-07T15:18:32.577Z] Requires: python3-rpm >= 4.14.2-35 [2021-07-07T15:18:32.577Z] Error: Package: python3-dnf-4.7.0-1.el8.noarch (centos-base-el8stream) [2021-07-07T15:18:32.578Z] Requires: python3-hawkey >= 0.61.1 [2021-07-07T15:18:32.578Z] Error: Package: python3-dnf-4.7.0-1.el8.noarch (centos-base-el8stream) [2021-07-07T15:18:32.578Z] Requires: python3-libdnf [2021-07-07T15:18:32.578Z] Error: Package: python3-dnf-4.7.0-1.el8.noarch (centos-base-el8stream) [2021-07-07T15:18:32.578Z] Requires: /usr/libexec/platform-python [2021-07-07T15:18:32.578Z] Error: Package: python3-six-1.11.0-8.el8.noarch (centos-base-el8stream) [2021-07-07T15:18:32.578Z] Requires: python(abi) = 3.6 [2021-07-07T15:18:32.578Z] Error: Package: python3-dnf-4.7.0-1.el8.noarch (centos-base-el8stream) [2021-07-07T15:18:32.578Z] Requires: python3-gpg [2021-07-07T15:18:32.578Z] You could try using --skip-broken to work around the problem [2021-07-07T15:18:32.578Z] You could try running: rpm -Va --nofiles --nodigest I initially thought it was a repo issue on centos stream side and reported it at https://bugzilla.redhat.com/show_bug.cgi?id=1979601 But it sorted out it's a CI configuration issue. The proof repositories are fine: LC_ALL=C sudo dnf --disablerepo=* --repofrompath=baseos1, http://mirror.centos.org/centos/8/BaseOS/ppc64le/os/ --enablerepo=baseos1 --releasever=8 --installroot=/tmp/test --nogpgcheck install :qdnf dnf-plugins-core --setopt=tsflags=nocontexts --setopt=arch=ppc64le correctly install the needed packages. This is blocking CI on ppc64le architecture. -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

1 4

Please resync centos-stream-el8stream/base mirror
by Sandro Bonazzola 07 Jul '21

07 Jul '21

Looks like the mirror needs a re-sync: [2021-07-07T06:24:14.859Z] [MIRROR] libpmem-1.6.1-1.el8.x86_64.rpm: Status code: 404 for http://mirrors.phx.ovirt.org/repos/yum/centos-stream-el8stream/base/Package… (IP: 66.187.230.49) [2021-07-07T06:24:14.859Z] [MIRROR] libpmem-1.6.1-1.el8.x86_64.rpm: Status code: 404 for http://mirrors.phx.ovirt.org/repos/yum/centos-stream-el8stream/base/Package… (IP: 66.187.230.49) [2021-07-07T06:24:14.859Z] [MIRROR] libpmem-1.6.1-1.el8.x86_64.rpm: Status code: 404 for http://mirrors.phx.ovirt.org/repos/yum/centos-stream-el8stream/base/Package… (IP: 66.187.230.49) [2021-07-07T06:24:14.859Z] [FAILED] libpmem-1.6.1-1.el8.x86_64.rpm: Status code: 404 for http://mirrors.phx.ovirt.org/repos/yum/centos-stream-el8stream/base/Package… (IP: 66.187.230.49) [2021-07-07T06:24:14.859Z] Error: Error downloading packages: [2021-07-07T06:24:14.859Z] Status code: 404 for http://mirrors.phx.ovirt.org/repos/yum/centos-stream-el8stream/base/Package… (IP: 66.187.230.49) Thanks -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

4 3

Reminder: oVirt conference call for papers closes in 20 days
by Sandro Bonazzola 05 Jul '21

05 Jul '21

A kind reminder that oVirt conference call for papers closes in 20 days! Looking forward to user stories, developers onboarding journeys, integration stories, new features presentation, old features nobody knows about because nobody presented them before and more you see fit. You can find call for paper at https://blogs.ovirt.org/ovirt-2021-online-conference/ Thanks, -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

1 0