- Devel - oVirt List Archives

[NOTICE] Failing randomly on get_host_hooks with a NullPointerException
by Dafna Ron 26 Mar '19

26 Mar '19

Hi, we are randomly failing on get_host_hooks test for at least 3 weeks. its not a specific branch or project and there are no commonalities that I can see, aside from not being able to communicate with the host. this week its started happening at least once a day (this morning, 2 out of 3 failures were due to that test). This test has been added by Yaniv Kaul over a year ago and he is no longer working on ovirt I think someone else should take ownership of this test and fix it. Please let me know if you are intending to investigate and either fix the failure or fix the test if not I will add a skip to the test, Thanks, Dafna

5 13

the mess with uploading files
by Hetz Ben Hamo 26 Mar '19

26 Mar '19

Hi, Since both export and ISO domain are being deprecated, the only place to upload remains the data domain. This method works, however, it doesn't "look" good. Uploading few ISO files and you won't see any problem. Upload 50-70 files, and the "directory" looks very messy. So, my question, will there be any "structure" then can be created, like "folders" to put those uploaded files? Thanks Hetz

2 1

ovirt-engine has been tagged (ovirt-engine-4.3.3.1)
by Tal Nisan 26 Mar '19

26 Mar '19

1 0

ovirt-engine has been tagged (ovirt-engine-4.3.3)
by Tal Nisan 26 Mar '19

26 Mar '19

1 0

vdsm has been tagged (v4.30.12)
by Milan Zamazal 26 Mar '19

26 Mar '19

1 0

FYI - Many nightly suites, including Network, HE and HC are failing since 2-3 days ago
by Eyal Edri 26 Mar '19

26 Mar '19

Not sure if all the same issue, but seems to failing around the same time: ovirt-system-tests_hc-basic-suite-4.2 1 day 12 hr - #824 12 hr - #825 57 min integ-tests ovirt-system-tests_hc-basic-suite-master 2 days 12 hr - #1043 12 hr - #1045 51 min integ-tests ovirt-system-tests_he-basic-ansible-suite-4.3 N/A 11 hr - #11 24 sec integ-tests ovirt-system-tests_he-basic-ipv6-suite-master N/A 12 hr - #11 10 min integ-tests ovirt-system-tests_he-basic-iscsi-suite-master 2 days 10 hr - #871 10 hr - #873 1 hr 36 min integ-tests ovirt-system-tests_he-basic-suite-master 2 days 11 hr - #1147 11 hr - #1149 1 hr 26 min integ-tests ovirt-system-tests_he-node-ng-suite-master 2 days 12 hr - #727 12 hr - #729 1 hr 54 min integ-tests ovirt-system-tests_network-suite-master 3 days 12 hr - #926 12 hr - #929 45 min integ-tests ovirt-system-tests_openshift-on-ovirt-suite-4.2 3 days 10 hr - #187 10 hr - #190 45 min integ-tests Links to jobs can be found here: https://jenkins.ovirt.org/ -- Eyal edri MANAGER RHV/CNV 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)

7 13

Lago's local sync repo not available in OST
by Sandro Bonazzola 25 Mar '19

25 Mar '19

Hi, just seen: 2019-03-25 10:41:36,062-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-hostUpdatesChecker-Thread-2) [] EVENT_ID: HOST_AVAILABLE_UPDATES_FAILED(839), Failed to check for available updates on host lago-basic-suite-master-host-1 with message 'Failed to run check-update of host 'lago-basic-suite-master-host-1'. Error: fatal: [lago-basic-suite-master-host-1]: FAILED! => {"changed": false, "msg": " http://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\nhttp:// 192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\nhttp:// 192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\nhttp:// 192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\nhttp:// 192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\nhttp:// 192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\n\n\n One of the configured repositories failed (Latest oVirt nightly),\n and yum doesn't have enough cached data to continue. At this point the only\n safe thing yum can do is fail. There are a few ways to work \"fix\" this:\n\n 1. Contact the upstream for the repository and get them to fix the problem.\n\n 2. Reconfigure the baseurl/etc. for the repository, to point to a working\n upstream. This is most often useful if you are using a newer\n distribution release than is supported by the repository (and the\n packages for the previous distribution release still work).\n\n 3. Run the command with the repository temporarily disabled\n yum --disablerepo=alocalsync ...\n\n 4. Disable the repository permanently, so yum won't use it by default. Yum\n will then just ignore the repository until you permanently enable it\n again or use --enablerepo for temporary usage:\n\n yum-config-manager --disable alocalsync\n or\n subscription-manager repos --disable=alocalsync\n\n 5. Configure the failing repository to be skipped, if it is unavailable.\n Note that yum will try to contact the repo. when it runs most commands,\n so will have to try and fail each time (and thus. yum will be be much\n slower). If it is a very temporary problem though, this is often a nice\n compromise:\n\n yum-config-manager --save --setopt=alocalsync.skip_if_unavailable=true\n\nfailure: repodata/repomd.xml from alocalsync: [Errno 256] No more mirrors to try.\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nCannot upload enabled repos report, is this client registered?\n", "rc": 1, "results": []} while looking at https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/3867/… for https://gerrit.ovirt.org/98862 Can you please have a look? -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 3

[OST upgrade suite] Looking for maintainer
by Ales Musil 25 Mar '19

25 Mar '19

Hi, I am not sure who is currently maintainer for the upgrade suite, but please take a look at [1]. This patch is testing the engine upgrade issue with database vm_id and vmt_id in interface table [2]. And at the same time serves as opening patch to put more sophisticated tests into upgrade suite. Thank you. Regards, Ales [1] https://gerrit.ovirt.org/c/98656/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=1547038 -- ALES MUSIL Associate Software Engineer - rhv network Red Hat EMEA <https://www.redhat.com/> amusil(a)redhat.com IM: amusil <https://red.ht/sig>

3 6

[OST][master] hc-basic-suite-master failing on OVF_STORE not ready
by Sandro Bonazzola 25 Mar '19

25 Mar '19

Job is: https://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-master/1054… Logs show: *03:19:46* TASK [ovirt.hosted_engine_setup : Wait for OVF_STORE disk content] **************03:19:47* FAILED - RETRYING: Wait for OVF_STORE disk content (12 retries left).*03:19:58* FAILED - RETRYING: Wait for OVF_STORE disk content (11 retries left).*03:20:09* FAILED - RETRYING: Wait for OVF_STORE disk content (10 retries left).*03:20:19* FAILED - RETRYING: Wait for OVF_STORE disk content (9 retries left).*03:20:30* FAILED - RETRYING: Wait for OVF_STORE disk content (8 retries left).*03:20:41* FAILED - RETRYING: Wait for OVF_STORE disk content (7 retries left).*03:20:52* FAILED - RETRYING: Wait for OVF_STORE disk content (6 retries left).*03:21:03* FAILED - RETRYING: Wait for OVF_STORE disk content (5 retries left).*03:21:14* FAILED - RETRYING: Wait for OVF_STORE disk content (4 retries left).*03:21:25* FAILED - RETRYING: Wait for OVF_STORE disk content (3 retries left).*03:21:36* FAILED - RETRYING: Wait for OVF_STORE disk content (2 retries left).*03:21:46* FAILED - RETRYING: Wait for OVF_STORE disk content (1 retries left).*03:21:57* failed: [localhost] (item={u'image_id': u'7df4f0be-0192-4e8b-bb6d-ee4cfd2a45d0', u'name': u'OVF_STORE', u'id': u'c55ba7d1-10cf-4f71-a9d2-59cf4ccb08e1'}) => {"attempts": 12, "changed": true, "cmd": "vdsm-client Image prepare storagepoolID=b9c1cfba-4ea2-11e9-b48c-00163e24d363 storagedomainID=a35d1e26-790d-4da6-90d1-df654cbfc0f3 imageID=c55ba7d1-10cf-4f71-a9d2-59cf4ccb08e1 volumeID=7df4f0be-0192-4e8b-bb6d-ee4cfd2a45d0 | grep path | awk '{ print $2 }' | xargs -I{} sudo -u vdsm dd if={} | tar -tvf - 5f87c4b6-2141-4d0c-8ce6-8bb1da97aeb6.ovf", "delta": "0:00:00.578484", "end": "2019-03-24 22:21:57.660496", "item": {"id": "c55ba7d1-10cf-4f71-a9d2-59cf4ccb08e1", "image_id": "7df4f0be-0192-4e8b-bb6d-ee4cfd2a45d0", "name": "OVF_STORE"}, "msg": "non-zero return code", "rc": 2, "start": "2019-03-24 22:21:57.082012", "stderr": "tar: 5f87c4b6-2141-4d0c-8ce6-8bb1da97aeb6.ovf: Not found in archive\ntar: Exiting with failure status due to previous errors\n20+0 records in\n20+0 records out\n10240 bytes (10 kB) copied, 0.00214885 s, 4.8 MB/s", "stderr_lines": ["tar: 5f87c4b6-2141-4d0c-8ce6-8bb1da97aeb6.ovf: Not found in archive", "tar: Exiting with failure status due to previous errors", "20+0 records in", "20+0 records out", "10240 bytes (10 kB) copied, 0.00214885 s, 4.8 MB/s"], "stdout": "", "stdout_lines": []} -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 1

[Ovirt] [CQ weekly status] [22-03-2019]
by Dafna Ron 22 Mar '19

22 Mar '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.2*: GREEN (#1) Last CQ job failure on 4.2 was 21-03-2019 on project ovirt-hosted-engine-setup due to access to repo centos-cr-el7 in mirrors. this can be solved by projects setting their repo list to work with CI local mirrors. *CQ-4.3*: RED (#1) vdsm is failing on 4.3 due to failure in add_master_storage_domain. this issue is currently investigated by Marcin Sobczyk *CQ-Master:* RED (#1) we are failing on project ovirt-engine for test hotplug_cpu. this was debugged by Evgheni and myself to determine that the issue is indeed in ovirt and not in infra. The test is failing as the internal vm is not responding and we cannot ssh to vm0. *There is a random failure for test get_host_hooks. * It fails on all branches and I can see a NPE in the engine log. The test owner was Yaniv Kaul and Marcin Sobczyk is now looking into the failure. I created a skiptest patch but I am hoping that this would be resolved soon so we do not have to use it. Current running jobs for 4.2 [1], 4.3 [2] and master [3] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.2_change-qu… [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.3_change-q… [3] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change… Happy week! Dafna ------------------------------------------------------------------------------------------------------------------- COLOUR MAP Green = job has been passing successfully ** green for more than 3 days may suggest we need a review of our test coverage 1. 1-3 days GREEN (#1) 2. 4-7 days GREEN (#2) 3. Over 7 days GREEN (#3) Yellow = intermittent failures for different projects but no lasting or current regressions ** intermittent would be a healthy project as we expect a number of failures during the week ** I will not report any of the solved failures or regressions. 1. Solved job failures YELLOW (#1) 2. Solved regressions YELLOW (#2) Red = job has been failing ** Active Failures. The colour will change based on the amount of time the project/s has been broken. Only active regressions would be reported. 1. 1-3 days RED (#1) 2. 4-7 days RED (#2) 3. Over 7 days RED (#3)

1 0