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

Milan Zamazal <mzamazal(a)redhat.com&gt; writes: > 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. Or could it be an issue, under some circumstances, with using float in the computation (which is wrong anyway)? Let's try: https://gerrit.ovirt.org/c/vdsm/+/116182