[ovirt-devel] Re: [VDSM] CI fails in QemuGuestAgentTests.test_pci_devices

Milan Zamazal <mzamazal(a)redhat.com&gt; writes: > Nir Soffer <nsoffer(a)redhat.com&gt; writes: > >> VDSM CI is failing now consistently. Last related change is: >> https://gerrit.ovirt.org/c/vdsm/+/116090 > > It doesn't look related. > >> Build: >> https://jenkins.ovirt.org/job/vdsm_standard-check-patch/29212//artifact/c... >> >> _____________________ QemuGuestAgentTests.test_pci_devices _____________________ >> >> self = <virt.qemuguestagent_test.QemuGuestAgentTests >> testMethod=test_pci_devices> >> >> def test_pci_devices(self): >> devices = self.qga_poller._qga_call_get_devices(self.vm)['pci_devices'] >> # Ethernet is returned twice by the agent but should appear only >> # once in the list >> assert len(devices) == 2 >> eth = [d for d in devices if d['device_id'] == 4096][0] >> assert eth == { >> 'device_id': 4096, >> 'driver_date': '2019-08-12', >> 'driver_name': 'Red Hat VirtIO Ethernet Adapter', >> 'driver_version': '100.80.104.17300', >> 'vendor_id': 6900, >> } >> balloon = [d for d in devices if d['device_id'] == 4098][0] >>> assert balloon == { >> 'device_id': 4098, >> 'driver_date': '2019-08-12', >> 'driver_name': 'VirtIO Balloon Driver', >> 'driver_version': '100.80.104.17300', >> 'vendor_id': 6900, >> } >> E AssertionError: assert {'device_id':...4.17300', ...} == >> {'device_id':...4.17300', ...} >> E Omitting 4 identical items, use -vv to show >> E Differing items: >> E {'driver_date': '2019-08-11'} != {'driver_date': '2019-08-12'} >> >> Are we using real time in this test? > > No, I think the problem is related to the following line > > 'driver-date': 1565568000000000000, > > in qemuguestagent_test.py and the corresponding conversion > > date = datetime.date.fromtimestamp(date // 1e9).isoformat() > > in guestagenthelpers.py. > > The test passes on my computer so I wonder whether it may be a bug in > some version of python3-dateutil. I also wonder whether the fact that > it occurred on 12 August is just a coincidence. Looks correct also on current CentOS Stream 8: >>> datetime.datetime.fromtimestamp(1565568000000000000 // 1e9).isoformat() '2019-08-12T00:00:00' And there was no leap second this year that could cause it. I guess it could be fixed by shifting the driver timestamp a bit forward but then the test wouldn't check for these kinds of errors anymore. So I'd suggest disabling the test if it causes trouble until the failing part is identified.

>> E Use -v to get the full diff