- Devel - oVirt List Archives

URGENT - ovirt-engine master is failing for the past 9 days
by Dafna Ron 03 Sep '19

03 Sep '19

Hi, We have been failing CQ master for project ovirt-engine for the past 9 days. this was reported last week and we have not yet seen a fix for this issue. the patch reported by CQ is https://gerrit.ovirt.org/#/c/101913/10 - core: Change CPU config to secure/insecure concept logs for latest failure can be found here: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15638/artifac… Error: 2019-09-01 06:31:17,248-04 INFO [org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-1) [174bc463-9a98-441f-ad14-4d97fefde4fa] Running command: UpdateClusterCommand internal: false. Entities affected : ID: 0407bc06-4bef-4c47-99e1-0e42f9ced996 Type: ClusterAction group EDIT_CLUSTER_CONFIGURATION with role type ADMIN 2019-09-01 06:31:17,263-04 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1) [174bc463-9a98-441f-ad14-4d97fefde4fa] EVENT_ID: CLUSTER_UPDATE_CPU_WHEN_DEPRECATED(9,029), Modified the CPU Type to Intel Haswell-noTSX Family when upgrading the Compatibility Version of Cluster test-cluster because the previous CPU Type was deprecated. 2019-09-01 06:31:17,319-04 WARN [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-1) [18fd7817] Validation of action 'UpdateVm' failed for user admin@internal-authz. Reasons: VAR__ACTION__UPDATE,VAR__TYPE__VM,ACTION_TYPE_FAILED_ILLEGAL_OS_TYPE_IS_NOT_SUPPORTED_BY_ARCHITECTURE_TYPE 2019-09-01 06:31:17,329-04 WARN [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-1) [62694a6a] Validation of action 'UpdateVm' failed for user admin@internal-authz. Reasons: VAR__ACTION__UPDATE,VAR__TYPE__VM,ACTION_TYPE_FAILED_ILLEGAL_OS_TYPE_IS_NOT_SUPPORTED_BY_ARCHITECTURE_TYPE 2019-09-01 06:31:17,334-04 WARN [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-1) [10e41cd3] Validation of action 'UpdateVm' failed for user admin@internal-authz. Reasons: VAR__ACTION__UPDATE,VAR__TYPE__VM,ACTION_TYPE_FAILED_ILLEGAL_OS_TYPE_IS_NOT_SUPPORTED_BY_ARCHITECTURE_TYPE 2019-09-01 06:31:17,345-04 WARN [org.ovirt.engine.core.bll.UpdateVmTemplateCommand] (default task-1) [26a471dd] Validation of action 'UpdateVmTemplate' failed for user admin@internal-authz. Reasons: VAR__ACTION__UPDATE,VAR__TYPE__VM_TEMPLATE,VMT_CANNOT_UPDATE_ILLEGAL_FIELD 2019-09-01 06:31:17,352-04 WARN [org.ovirt.engine.core.bll.UpdateVmTemplateCommand] (default task-1) [32fd89b5] Validation of action 'UpdateVmTemplate' failed for user admin@internal-authz. Reasons: VAR__ACTION__UPDATE,VAR__TYPE__VM_TEMPLATE,VMT_CANNOT_UPDATE_ILLEGAL_FIELD 2019-09-01 06:31:17,363-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1) [32fd89b5] EVENT_ID: CLUSTER_CANNOT_UPDATE_VM_COMPATIBILITY_VERSION(12,005), Cannot update compatibility version of Vm/Template: [vm-with-iface], Message: [No Message] 2019-09-01 06:31:17,371-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1) [32fd89b5] EVENT_ID: CLUSTER_CANNOT_UPDATE_VM_COMPATIBILITY_VERSION(12,005), Cannot update compatibility version of Vm/Template: [vm-with-iface-template], Message: [No Message] 2019-09-01 06:31:17,380-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1) [32fd89b5] EVENT_ID: CLUSTER_CANNOT_UPDATE_VM_COMPATIBILITY_VERSION(12,005), Cannot update compatibility version of Vm/Template: [vm0], Message: [No Message] 2019-09-01 06:31:17,388-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1) [32fd89b5] EVENT_ID: CLUSTER_CANNOT_UPDATE_VM_COMPATIBILITY_VERSION(12,005), Cannot update compatibility version of Vm/Template: [vm1], Message: [No Message] 2019-09-01 06:31:17,405-04 INFO [org.ovirt.engine.core.bll.CommandCompensator] (default task-1) [32fd89b5] Command [id=50898f00-4956-484a-94ff-f273adc2e93e]: Compensating UPDATED_ONLY_ENTITY of org.ovirt.engine.core.common.businessentities.Cluster; snapshot: Cluster [test-cluster]. 2019-09-01 06:31:17,422-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1) [32fd89b5] EVENT_ID: USER_UPDATE_CLUSTER_FAILED(812), Failed to update Host cluster (User: admin@internal-authz) 2019-09-01 06:31:17,422-04 INFO [org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-1) [32fd89b5] Lock freed to object 'EngineLock:{exclusiveLocks='[5d3b2f0f-f05f-41c6-b61a-c517704f79fd=TEMPLATE, 728f5530-4e34-4c92-beef-ca494ec104b9=TEMPLATE]', sharedLocks='[a107316a-a961-403f-adb2-d01f22f0b8f1=VM, dc3a2ad8-6019-4e00-85e5-d9fba7390d4f=VM, 6348722f-61ae-40be-a2b8-bd9d086b06dc=VM]'}' 2019-09-01 06:31:17,424-04 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-1) [] Operation Failed: [Update of cluster compatibility version failed because there are VMs/Templates [vm-with-iface, vm-with-iface-template, vm0, vm1] with incorrect configuration. To fix the issue, please go to each of them, edit, change the Custom Compatibility Version of the VM/Template to the cluster level you want to update the cluster to and press OK. If the save does not pass, fix the dialog validation. After successful cluster update, you can revert your Custom Compatibility Version change.] (END)

3 6

unicode_literrals vs "u''" vs six.text_type
by Yedidyah Bar David 02 Sep '19

02 Sep '19

Hi all, That's a "sub-thread" of "unicode sandwich in otopi/engine-setup". I was recommended to use 'six.text_type() over "u''". I did read [1], and eventually decided that my own preference is to just add "u" prefix. Reasoning is inside [1]. Do people have different preferences/reasoning they want to share? Do people think we should have project-wide policy re this? Personally, I do not see the big advantage of adding "six.text_type()" (15 chars) instead of a single "u". I do see where it can be useful, but not as a very long replacement, IMO, for "u", or for unicode_literrals. Thanks and best regards, [1] http://python-future.org/unicode_literals.html -- Didi

2 5

[oVirt] [CQ weekly status] [30-08-2019]
by Dusan Fodor 30 Aug '19

30 Aug '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*: NOT RELEVANT This CQ is not followed anymore, since it's about to be decommissioned. *CQ-4.3*: YELLOW (#1) Last failure was on 28-08 for ovirt-web-ui. It was solved soon after by change 57c5c4b. *CQ-Master:* RED (#1) Last failure was on 30-08 for ovirt-engine in host-deployment. This issue is under investigation. 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-queue-tester/ [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -4.3_change-queue-tester/ [3] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -master_change-queue-tester/ Have a nice week! Dusan ------------------------------------------------------------------------------------------------------------------- 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) _______________________________________________ Devel mailing list -- devel(a)ovirt.org To unsubscribe send an email to devel-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt .org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt .org/message/YCNCKRK3G4EJXA3OCYAUS4VMKRDA67F4/

1 0

Failure adding host due to missing 'ovirt_host_deploy'
by Eyal Shenitzky 29 Aug '19

29 Aug '19

Hi all, I am failing to add a new host to oVirt environment, the engine runs on fedora-30. ovirt_host_deploy isn't found under - http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc30 I installed the fc29 version. *Error:* File "/tmp/ovirt-biYslZJETn/otopi-plugins/ovirt-host-deploy/kdump/packages.py", line 37, in <module> from ovirt_host_deploy import constants as odeploycons otopi.main.PluginLoadException: No module named 'ovirt_host_deploy *Installed packages:* ovirt-host-deploy-common-1.9.0-0.0.master.20190722100027.git138fb90.fc29.noarch python2-ovirt-host-deploy-1.9.0-0.0.master.20190722100027.git138fb90.fc29.noarch ovirt-host-deploy-common-1.9.0-0.0.master.20190722100027.git138fb90.fc29.noarch Does someone encounter that issue? Thanks, -- Regards, Eyal Shenitzky

3 4

Nominate Sharon and Michal as ovirt-engine-nodejs-modules maintainers
by Vojtech Szocs 28 Aug '19

28 Aug '19

Hi everyone, I'd like to nominate Sharon and Michal as ovirt-engine-nodejs-modules <https://gerrit.ovirt.org/#/admin/projects/ovirt-engine-nodejs-modules> project maintainers. This project is a build-time dependency of oVirt web-related projects, providing the required npm (JavaScript) dependencies via single RPM package. Projects that depend on ovirt-engine-nodejs-modules include (see here <https://gerrit.ovirt.org/gitweb?p=ovirt-engine-nodejs-modules.git;a=blob_pl…> for details): - ovirt-web-ui <https://github.com/oVirt/ovirt-web-ui> (next-gen User Portal) - ovirt-engine-ui-extensions <https://gerrit.ovirt.org/#/admin/projects/ovirt-engine-ui-extensions> (UI plugin for Admin Portal) - cockpit-ovirt <https://gerrit.ovirt.org/#/admin/projects/cockpit-ovirt> (plugins for Cockpit) Both Sharon and Michal are familiar with these projects and having them as maintainers would help with resolving any issues related to oVirt JS dependencies. Thanks, Vojtech

6 5

OST upgrade-from-release-suite-master update_cluster_versions failing
by Dominik Holler 28 Aug '19

28 Aug '19

Hi, for me OST upgrade-from-release-suite-master update_cluster_versions is failing with 004_basic_sanity.update_cluster_versions (from nosetests) Failing for the past 1 build (Since Failed#5442 ) Took 1 min 16 sec. add description Error Message Fault reason is "Operation Failed". Fault detail is "[Update of cluster compatibility version failed because there are VMs/Templates [vm-with-iface, vm-with-iface-template, vm0, vm1] with incorrect configuration. To fix the issue, please go to each of them, edit, change the Custom Compatibility Version of the VM/Template to the cluster level you want to update the cluster to and press OK. If the save does not pass, fix the dialog validation. After successful cluster update, you can revert your Custom Compatibility Version change.]". HTTP response code is 500. Stacktrace Traceback (most recent call last): File "/usr/lib64/python2.7/unittest/case.py", line 369, in run testMethod() File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 142, in wrapped_test test() File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 60, in wrapper return func(get_test_prefix(), *args, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 79, in wrapper prefix.virt_env.engine_vm().get_api(api_ver=4), *args, **kwargs File "/home/jenkins/workspace/ovirt-system-tests_manual/ovirt-system-tests/upgrade-from-release-suite-master/test-scenarios-after-upgrade/004_basic_sanity.py", line 184, in update_cluster_versions minor=minor File "/home/jenkins/workspace/ovirt-system-tests_manual/ovirt-system-tests/upgrade-from-release-suite-master/test-scenarios-after-upgrade/004_basic_sanity.py", line 130, in _update_cluster_version version=new_version File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py", line 3943, in update return self._internal_update(cluster, headers, query, wait) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 253, in _internal_update return future.wait() if wait else future File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 55, in wait return self._code(response) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 250, in callback self._check_fault(response) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 132, in _check_fault self._raise_error(response, body) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 118, in _raise_error raise error Error: Fault reason is "Operation Failed". Fault detail is "[Update of cluster compatibility version failed because there are VMs/Templates [vm-with-iface, vm-with-iface-template, vm0, vm1] with incorrect configuration. To fix the issue, please go to each of them, edit, change the Custom Compatibility Version of the VM/Template to the cluster level you want to update the cluster to and press OK. If the save does not pass, fix the dialog validation. After successful cluster update, you can revert your Custom Compatibility Version change.]". HTTP response code is 500. Please find an example run in https://jenkins.ovirt.org/view/oVirt system tests/job/ovirt-system-tests_manual/5442 Is this a known error, or is someone already addressing this issue? Thanks Dominik

3 10

mailing list
by Hetz Ben Hamo 28 Aug '19

28 Aug '19

Hi, Any chance that someone will take a look at the ovirt mailing list server? Trying to access https://lists.ovirt.org/archives/list/devel%40ovirt.org/ gives error 500 Thanks תודה, *חץ בן חמו* אתם מוזמנים לבקר בבלוג היעוץ <http://linvirtstor.net/> או בבלוג הפרטי שלי <http://benhamo.org>

2 1

ovirt-engine has been tagged (ovirt-engine-4.3.6.4)
by Tal Nisan 27 Aug '19

27 Aug '19

1 0

CI fails - tox error
by Pavel Bar 26 Aug '19

26 Aug '19

Hi, We experience problems with failed CI on VDSM patches. Examples: http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10633/ http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10634/ http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10635/ This is what we see in logs: out=`tox --version`; \ if [ $? -ne 0 ]; then \ echo "Error: cannot run tox, please install tox \ 2.9.1 or later"; \ exit 1; \ fi; \ version=`echo $out | cut -d' ' -f1`; \ if python2.7 build-aux/vercmp $version 2.9.1; then \ echo "Error: tox is too old, please install tox \ 2.9.1 or later"; \ exit 1; \ fi Traceback (most recent call last): File "/usr/bin/tox", line 7, in <module> from tox import cmdline File "/usr/lib/python2.7/site-packages/tox/__init__.py", line 4, in <module> from .hookspecs import hookimpl File "/usr/lib/python2.7/site-packages/tox/hookspecs.py", line 4, in <module> from pluggy import HookimplMarker File "/usr/lib/python2.7/site-packages/pluggy/__init__.py", line 16, in <module> from .manager import PluginManager, PluginValidationError File "/usr/lib/python2.7/site-packages/pluggy/manager.py", line 6, in <module> import importlib_metadata File "/usr/lib/python2.7/site-packages/importlib_metadata/__init__.py", line 9, in <module> import zipp File "/usr/lib/python2.7/site-packages/zipp.py", line 12, in <module> import more_itertools File "/usr/lib/python2.7/site-packages/more_itertools/__init__.py", line 1, in <module> from more_itertools.more import * # noqa File "/usr/lib/python2.7/site-packages/more_itertools/more.py", line 340 def _collate(*iterables, key=lambda a: a, reverse=False): ^ SyntaxError: invalid syntax Error: cannot run tox, please install tox 2.9.1 or later make: *** [tox] Error 1 + teardown + res=2 + '[' 2 -ne 0 ']' + echo '*** err: 2' *** err: 2 + collect_logs + tar --directory /var/log --exclude 'journal/*' -czf /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/mock_varlogs.tar.gz . + tar --directory /var/host_log --exclude 'journal/*' -czf /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/host_varlogs.tar.gz . + teardown_storage + python2 tests/storage/userstorage.py teardown Can someone look at it? Thank you in advance! Pavel

3 3

[oVirt] [CQ weekly status] [25-08-2019]
by Dusan Fodor 25 Aug '19

25 Aug '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 (#2) Last failure was on 20-08 for ovirt-ansible-hosted-engine-setup. It was caused by random network issue (fetching repo from github), retriggered job for the change passed well. *CQ-4.3*: GREEN (#2) Last failure was on 20-08 for ovirt-ansible-hosted-engine-setup. It was caused by random network issue, retriggered job for the change passed well. *CQ-Master:* RED (#1) Last failure was on 25-08 for ovirt-engine, caused by failed cloning of engine repo (even with lately increased timeout value 20min). Related ticket from last time was reopened. 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-queue-tester/ [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -4.3_change-queue-tester/ [3] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -master_change-queue-tester/ Have a nice week! Dusan ------------------------------------------------------------------------------------------------------------------- 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) _______________________________________________ Devel mailing list -- devel(a)ovirt.org To unsubscribe send an email to devel-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt .org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt .org/message/YCNCKRK3G4EJXA3OCYAUS4VMKRDA67F4/

1 0