- Devel - oVirt List Archives

[VDSM] Remove fcraw build as gating
by Edward Haas 22 Mar '18

22 Mar '18

Hi All, Fcraw build on VDSM check-patch has been failing recently (again). fcraw cannot act as gating to the VDSM CI, as it is unstable (by definition). If there is a strong interest for some to track VDSM against this unstable distribution, it better be performed in parallel to the VDSM developing flow. With the current state, we are unable to trust the CI and it causes us to either overwrite its output (which I consider very bad) or just get stuck frequently. Could we please move this job to be triggered once a day as a nightly job and whoever is interested in its output to get notifications for it? Please. lets not make it a gating to VDSM development. Thanks, Edy.

3 3

[vdsm][maintainership] proposal for a new stable branch policy
by Francesco Romani 21 Mar '18

21 Mar '18

Hi all, Recently Milan, Petr and me discussed the state of ovirt.4.2, considering that release 4.2.2 is still pending and this prevents merging of patches in the sub-branch ovirt-4.2. We agreed we could improve the handling of the stable branch(es), in order to make the process smoother and more predictable. Currently, we avoid doing Z- branches (e.g. ovirt-4.2.2, ovirt-4.2.3...) as much as we can, to avoid the hassle of double-backporting patches to stable branch. However, if a release hits unexpected delay, this policy causes different hassles: the Y-branch (ovirt-4.2, ovirt-4.3) is effectively locked, so patches already queued and ready for next releases can't be merged and need to wait. The new proposed policy is the following: - we will keep working exactly as now until we hit a certain RC version. We choosed RC3, a rule of thumb made out of experience. - if RC3 is final, everyone's happy and things resume as usual - if RC3 is NOT final, we will branch out at RC3 -- from that moment on, patches for next version could be accepted on the Y-branch -- stabilization of the late Z version will continue on the Z-branch -- patches will be backported twice Example using made up numbers - We just released ovirt 4.3.1 - We are working on the ovirt-4.3 branch - The last tag is v4.30.10, from ovirt-4.3 branch - We accept patches for ovirt 4.3.2 on the ovirt-4.3 branch - We keep collecting patches, until we tag v4.30.11 (oVirt 4.3.2 RC 1). Tag is made from ovirt-4.3 branch. - Same for tags 4.30.12 - oVirt 4.3.2 RC 2 and 4.30.13 - oVirt 4.3.2 RC 3. Both tags are made from ovirt-4.3 branch. - Damn, RC3 is not final. We branch out ovirt-4.3.2 form branch ovirt-4.3 from the same commit pointed by tag 4.30.13 - Next tags (4.30.13.1) for ovirt 4.3.2 will be taken from the ovirt-4.3.2 branch I believe this approach will make predictable for everyone if and when the branch will be made, so when the patches could be merged and where. The only drawback I can see - and that I realized while writing the example - is the version number which can be awkward: v4.30.11 -> 4.3.2 RC1 v4.30.12 -> 4.3.2 RC2 v4.30.13 -> 4.3.2 RC3 v4.30.13.1 -> 4.3.2 RC4 ?!?! v4.30.13.5 -> 4.3.2 RC5 ?!?! Perhaps we should move to four versions digit? So we could have v4.30.11.0 -> 4.3.2 RC1 v4.30.11.1 -> 4.3.2 RC2 v4.30.11.2 -> 4.3.2 RC3 v4.30.11.3 -> 4.3.2 RC4 v4.30.11.4 -> 4.3.2 RC5 I don't see any real drawback in using 4-digit versions by default, besides a minor increase in complexity, which is balanced by more predictable and consistent versions. Plus, we already had 4-digit versions in Vdsm, so packaging should work just fine. Please share your thoughts, -- Francesco Romani Senior SW Eng., Virtualization R&D Red Hat IRC: fromani github: @fromanirh

3 2

[vdsm] network test failure
by Francesco Romani 21 Mar '18

21 Mar '18

Hi all, we had a bogus failure on CI again, some network test failed and it seems totally unrelated to the patch being tested: http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/22410/conso… could someone please have a look? Bests, -- Francesco Romani Senior SW Eng., Virtualization R&D Red Hat IRC: fromani github: @fromanirh

4 4

[ OST Failure Report ] [ oVirt Master (Ovirt-ngine) ] [ 19-03-2018 ] [ 002_bootstrap.verify_notifier ]
by Dafna Ron 21 Mar '18

21 Mar '18

Hi, We had a failure in test 002_bootstrap.verify_notifier. I can't see anything wrong with the notifier and I don't think it should be related to the change that was reported. the test itself is looking for vdc_stop in messages which I do not indeed see but I am not sure what is the cause and how the reported change related to the failure. Can you please take a look? *Link and headline of suspected patches: * *core: USB in osinfo configuration depends on chipset - https://gerrit.ovirt.org/#/c/88777/ <https://gerrit.ovirt.org/#/c/88777/>Link to Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6429/ <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6429/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6429/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6429/artifacts>(Relevant) error snippet from the log: <error>* *this is the error from *the api: Error Message Failed grep for VDC_STOP with code 1. Output: -------------------- >> begin captured logging << -------------------- lago.ssh: DEBUG: start task:f1231b27-f796-406c-8618-17b0868725bc:Get ssh client for lago-basic-suite-master-engine: lago.ssh: DEBUG: end task:f1231b27-f796-406c-8618-17b0868725bc:Get ssh client for lago-basic-suite-master-engine: lago.ssh: DEBUG: Running 1cce7c0c on lago-basic-suite-master-engine: grep VDC_STOP /var/log/messages lago.ssh: DEBUG: Command 1cce7c0c on lago-basic-suite-master-engine returned with 1 --------------------- >> end captured logging << --------------------- Stacktrace 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 129, in wrapped_test test() File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 59, in wrapper return func(get_test_prefix(), *args, **kwargs) File "/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py", line 1456, in verify_notifier 'Failed grep for VDC_STOP with code {0}. Output: {1}'.format(result.code, result.out) File "/usr/lib/python2.7/site-packages/nose/tools/trivial.py", line 29, in eq_ raise AssertionError(msg or "%r != %r" % (a, b)) 'Failed grep for VDC_STOP with code 1. Output: \n-------------------- >> begin captured logging << --------------------\nlago.ssh: DEBUG: start task:f1231b27-f796-406c-8618-17b0868725bc:Get ssh client for lago-basic-suite-master-engine:\nlago.ssh: DEBUG: end task:f1231b27-f796-406c-8618-17b0868725bc:Get ssh client for lago-basic-suite-master-engine:\nlago.ssh: DEBUG: Running 1cce7c0c on lago-basic-suite-master-engine: grep VDC_STOP /var/log/messages\nlago.ssh: DEBUG: Command 1cce7c0c on lago-basic-suite-master-engine returned with 1\n--------------------- >> end captured logging << ---------------------' *</error>*

3 4

[ OST Failure Report ] [ oVirt Master (ovirt-engine) ] [ 19-03-2018 ] [002_bootstrap.add_instance_type ]
by Dafna Ron 21 Mar '18

21 Mar '18

Hi, We have a failure in test 002_bootstrap.add_instance_type. There seem to be a NullPointerException on template type which is causing this failure. The same change that was reported at the last failure is reported as the root cause for this failure as well, but I am not sure how it would cause this failure. Can you please check? *Link and headline of suspected patches: reported as failed: * *core: fix removal of vm-host device - https://gerrit.ovirt.org/#/c/89145/ <https://gerrit.ovirt.org/#/c/89145/>* *reported as root cause: * *core: USB in osinfo configuration depends on chipset - https://gerrit.ovirt.org/#/c/88777/ <https://gerrit.ovirt.org/#/c/88777/>* *Link to Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6431 <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6431>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6431/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6431/artifact…>(Relevant) error snippet from the log: <error>2018-03-19 04:59:01,040-04 INFO [org.ovirt.engine.core.bll.AddVmTemplateCommand] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] Lock Acquired to object 'EngineLock:{exclusiveLocks='[99a9dfb3-9a13-4595-a795-693493e722be=TEMPLATE, myinstancetype=TEMPLATE_NAME]', sharedLocks='[]'}'2018-03-19 04:59:01,087-04 INFO [org.ovirt.engine.core.bll.AddVmTemplateCommand] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] Running command: AddVmTemplateCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_TEMPLATE with role type USER2018-03-19 04:59:01,139-04 INFO [org.ovirt.engine.core.bll.storage.disk.CreateAllTemplateDisksCommand] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] Running command: CreateAllTemplateDisksCommand internal: true.2018-03-19 04:59:01,205-04 INFO [org.ovirt.engine.core.utils.transaction.TransactionSupport] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] transaction rolled back2018-03-19 04:59:01,205-04 ERROR [org.ovirt.engine.core.bll.AddVmTemplateCommand] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] Command 'org.ovirt.engine.core.bll.AddVmTemplateCommand' failed: null2018-03-19 04:59:01,205-04 ERROR [org.ovirt.engine.core.bll.AddVmTemplateCommand] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] Exception: java.lang.NullPointerException at org.ovirt.engine.core.bll.utils.EmulatedMachineUtils.getEffective(EmulatedMachineUtils.java:30) [bll.jar:] at org.ovirt.engine.core.bll.utils.EmulatedMachineUtils.getEffectiveChipset(EmulatedMachineUtils.java:21) [bll.jar:] at org.ovirt.engine.core.bll.utils.VmDeviceUtils.updateUsbSlots(VmDeviceUtils.java:744) [bll.jar:] at org.ovirt.engine.core.bll.utils.VmDeviceUtils.copyVmDevices(VmDeviceUtils.java:1519) [bll.jar:] at org.ovirt.engine.core.bll.utils.VmDeviceUtils.copyVmDevices(VmDeviceUtils.java:1565) [bll.jar:] at org.ovirt.engine.core.bll.AddVmTemplateCommand.lambda$executeCommand$4(AddVmTemplateCommand.java:362) [bll.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInNewTransaction(TransactionSupport.java:202) [utils.jar:] at org.ovirt.engine.core.bll.AddVmTemplateCommand.executeCommand(AddVmTemplateCommand.java:345) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1133) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1286) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1935) [bll.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:164) [utils.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:103) [utils.jar:] at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1346) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:400) [bll.jar:] at org.ovirt.engine.core.bll.executor.DefaultBackendActionExecutor.execute(DefaultBackendActionExecutor.java:13) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:468) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:450) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:403) [bll.jar:] at sun.reflect.GeneratedMethodAccessor149.invoke(Unknown Source) [:1.8.0_161] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_161] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_161] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:92) [wildfly-weld-ejb-11.0.0.Final.jar:11.0.0.Final] at org.jboss.weld.interceptor.proxy.WeldInvocationContext.interceptorChainCompleted(WeldInvocationContext.java:98) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:117) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.ovirt.engine.core.common.di.interceptor.LoggingInterceptor.apply(LoggingInterceptor.java:12) [common.jar:] at sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source) [:1.8.0_161] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_161] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_161] at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.bean.InterceptorImpl.intercept(InterceptorImpl.java:108) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:82) [wildfly-weld-ejb-11.0.0.Final.jar:11.0.0.Final] at org.jboss.as.weld.interceptors.EjbComponentInterceptorSupport.delegateInterception(EjbComponentInterceptorSupport.java:60) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:76) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:88) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.ovirt.engine.core.bll.interceptors.CorrelationIdTrackerInterceptor.aroundInvoke(CorrelationIdTrackerInterceptor.java:13) [bll.jar:] at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source) [:1.8.0_161] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_161] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_161] at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:89) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422):* *End of error: * at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_161] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_161] at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_161] 2018-03-19 04:59:01,234-04 DEBUG [org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] Compiled stored procedure. Call string is [{call get_entity_snapshot_by_command_id(?)}] 2018-03-19 04:59:01,234-04 DEBUG [org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] SqlCall for procedure [get_entity_snapshot_by_command_id] compiled 2018-03-19 04:59:01,239-04 INFO [org.ovirt.engine.core.bll.CommandCompensator] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] Command [id=a7a51354-ae84-4109-a55e-b27558afbf2a]: Compensating NEW_ENTITY_ID of org.ovirt.engine.core.common.businessentities.VmTemplate; snapshot: 99a9dfb3-9a13-4595-a795-693493e722be. 2018-03-19 04:59:01,278-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] EVENT_ID: USER_ADD_VM_TEMPLATE_FAILURE(36), Failed creating Template myinstancetype. 2018-03-19 04:59:01,295-04 INFO [org.ovirt.engine.core.bll.AddVmTemplateCommand] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] Lock freed to object 'EngineLock:{exclusiveLocks='[99a9dfb3-9a13-4595-a795-693493e722be=TEMPLATE, myinstancetype=TEMPLATE_NAME]', sharedLocks='[]'}' 2018-03-19 04:59:01,295-04 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] method: runAction, params: [AddVmTemplate, AddVmTemplateParameters:{commandId='a7a51354-ae84-4109-a55e-b27558afbf2a', user='admin', commandType='AddVmTemplate'}], timeElapsed: 301ms 2018-03-19 04:59:01,301-04 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-5) [] Operation Failed: [Internal Engine Error] 2018-03-19 04:59:01,547-04 INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-83) [5a890b17-51ec-4398-8d64-82cc71939e6e] Command 'AddVmTemplate' id: 'a7a51354-ae84-4109-a55e-b27558afbf2a' execution didn't complete, not proceeding to perform the next operation 2018-03-19 04:59:01,547-04 INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-83) [5a890b17-51ec-4398-8d64-82cc71939e6e] Command 'AddVmTemplate' id: 'a7a51354-ae84-4109-a55e-b27558afbf2a' child commands '[8484f4d2-9ddf-48bd-9877-7c99ef555255]' executions were completed, status 'FAILED' 2018-03-19 04:59:01,581-04 INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-83) [db5dd3dd-8b48-4647-a02d-723fcd6a7dda] Command 'ImportRepoImage' (id: 'a6475141-53ef-4ecd-bc17-ee8eae168dc7') waiting on child command id: '528fde29-9b5b-4a90-b62a-606fac3cd6a6' type:'DownloadImage' to complete 2018-03-19 04:59:02,363-04 DEBUG [org.ovirt.otopi.dialog.MachineDialogParser] (VdsDeploy) [665e1c35] Got: ***L:INFO Yum install: 349/515: gdisk-0.8.6-5.el7.x86_64 2018-03-19 04:59:02,364-04 DEBUG [org.ovirt.otopi.dialog.MachineDialogParser] (VdsDeploy) [665e1c35] nextEvent: Log INFO Yum install: 349/515: gdisk-0.8.6-5.el7.x86_64 2018-03-19 04:59:02,570-04 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) [665e1c35] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), Installing Host lago-basic-suite-master-host-1. Yum install: 349/515: gdisk-0.8.6-5.el7.x86_64. 2018-03-19 04:59:02,666-04 ERROR [org.ovirt.engine.core.bll.AddVmTemplateCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-86) [5a890b17-51ec-4398-8d64-82cc71939e6e] Ending command 'org.ovirt.engine.core.bll.AddVmTemplateCommand' with failure. *</error>*

2 4

[ OST Failure Report ] [ oVirt 4.2 (ovirt-engine) ] [ 19-03-2018 ] [ 004_basic_sanity.verify_vm_import ]
by Dafna Ron 20 Mar '18

20 Mar '18

Hi, We have a failed change on test 004_basic_sanity.verify_vm_import. I can't see anything in the logs that suggests there was a problem with the import and the error in the junit also suggest this can possibly be in the api version. can you please check the issue? *Link and headline of suspected patches: * *core: Call endAction() of all child commands in ImportVmCommand - https://gerrit.ovirt.org/#/c/89165/ <https://gerrit.ovirt.org/#/c/89165/>Link to Job:http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1362 <http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1362>Link to all logs:http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1362/artifa… <http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1362/artifact/ex…>(Relevant) error snippet from the log: <error>2018-03-19 11:01:59,679-04 INFO [org.ovirt.engine.core.bll.exportimport.ImportVmCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-22) [] Lock freed to object 'EngineLock:{exclusiveLocks='[imported_vm=VM_NAME, 3494a94b-c253-440b-a6cb-c4c818b19ae1=VM]', sharedLocks='[cc4255e8-8e1d-4608-a3fe-a2096ed4e9f9=REMOTE_VM]'}'* Error Message False != True after 180 seconds 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 129, in wrapped_test test() File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 59, in wrapper return func(get_test_prefix(), *args, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 78, in wrapper prefix.virt_env.engine_vm().get_api(api_ver=4), *args, **kwargs File "/home/jenkins/workspace/ovirt-4.2_change-queue-tester/ovirt-system-tests/basic-suite-4.2/test-scenarios/004_basic_sanity.py", line 596, in verify_vm_import lambda: vm_service.get().status == types.VmStatus.DOWN File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 267, in assert_true_within_short assert_equals_within_short(func, True, allowed_exceptions) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 251, in assert_equals_within_short func, value, SHORT_TIMEOUT, allowed_exceptions=allowed_exceptions File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 237, in assert_equals_within '%s != %s after %s seconds' % (res, value, timeout) AssertionError: False != True after 180 seconds *</error>*

2 3

Bug 1557532 - CVE-2018-1000134 unboundid-ldapsdk: Incorrect Access Control vulnerability in process function in SimpleBindRequest class [fedora-all]
by Sandro Bonazzola 19 Mar '18

19 Mar '18

Hi, before I start building the same package for CentOS Virt SIG, please help testing the new 4.0.5 build on Fedora and ensure aaa-ldap package still work with the new build. If it works for you. please give karma to the build to allow it to be released to stable. unboundid-ldapsdk-4.0.5-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c188d3f09a unboundid-ldapsdk-4.0.5-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-0a473d6e7b unboundid-ldapsdk-4.0.5-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-e8635ed222 Thanks, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

1 0

[ OST Failure Report ] [ oVirt Master (cockpit-ovirt) ] [ 15-03-2018 ] [ 098_ovirt_provider_ovn.use_ovn_provider ]
by Dafna Ron 19 Mar '18

19 Mar '18

Hi, We have a failure on master for test 098_ovirt_provider_ovn.use_ovn_provider in project cockpit-ovirt. This seems to be a race because object is locked. also, the actual failure is logged as WARN and not ERROR. I don't think the patch is actually related to the failure but I think the test should be fixed. can you please review to make sure we do not have an actual regression and let me know if we need to open a bz to fix the test? *Link and headline of suspected patches: * *https://gerrit.ovirt.org/#/c/89020/2 <https://gerrit.ovirt.org/#/c/89020/2> - * *wizard: Enable scroll on start page for low-res screensLink to Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6374 <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6374>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6374/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6374/artifacts>(Relevant) error snippet from the log: <error>2018-03-15 10:05:00,160-04 DEBUG [org.ovirt.engine.core.sso.servlets.OAuthTokenInfoServlet] (default task-10) [] Sending json response2018-03-15 10:05:00,160-04 DEBUG [org.ovirt.engine.core.sso.utils.TokenCleanupUtility] (default task-10) [] Not cleaning up expired tokens2018-03-15 10:05:00,169-04 INFO [org.ovirt.engine.core.bll.provider.network.SyncNetworkProviderCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-90) [789edb23] Lock Acquired to object 'EngineLock:{exclusiveLocks='[c38a67ec-0b48-4e6f-be85-70c700df5483=PROVIDER]', sharedLocks=''}'2018-03-15 10:05:00,184-04 INFO [org.ovirt.engine.core.bll.provider.network.SyncNetworkProviderCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-90) [789edb23] Running command: SyncNetworkProviderCommand internal: true.2018-03-15 10:05:00,228-04 DEBUG [org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall] (default task-13) [e1328379-17b7-49f8-beb2-cf8331784828] Compiled stored procedure. Call string is [{call getdcidbyexternalnetworkid(?)}]2018-03-15 10:05:00,228-04 DEBUG [org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall] (default task-13) [e1328379-17b7-49f8-beb2-cf8331784828] SqlCall for procedure [GetDcIdByExternalNetworkId] compiled2018-03-15 10:05:00,229-04 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-13) [e1328379-17b7-49f8-beb2-cf8331784828] method: runQuery, params: [GetAllExternalNetworksOnProvider, IdQueryParameters:{refresh='false', filtered='false'}], timeElapsed: 353ms2018-03-15 10:05:00,239-04 INFO [org.ovirt.engine.core.bll.network.dc.AddNetworkCommand] (default task-13) [e1328379-17b7-49f8-beb2-cf8331784828] Failed to Acquire Lock to object 'EngineLock:{exclusiveLocks='[network_1=NETWORK, c38a67ec-0b48-4e6f-be85-70c700df5483=PROVIDER]', sharedLocks=''}'2018-03-15 10:05:00,239-04 WARN [org.ovirt.engine.core.bll.network.dc.AddNetworkCommand] (default task-13) [e1328379-17b7-49f8-beb2-cf8331784828] Validation of action 'AddNetwork' failed for user admin@internal-authz. Reasons: VAR__TYPE__NETWORK,VAR__ACTION__ADD,ACTION_TYPE_FAILED_PROVIDER_LOCKED,$providerId c38a67ec-0b48-4e6f-be85-70c700df54832018-03-15 10:05:00,240-04 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-13) [e1328379-17b7-49f8-beb2-cf8331784828] method: runAction, params: [AddNetwork, AddNetworkStoragePoolParameters:{commandId='61b365ec-27c1-49af-ad72-f907df8befcd', user='null', commandType='Unknown'}], timeElapsed: 10ms2018-03-15 10:05:00,250-04 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-13) [] Operation Failed: [Cannot add Network. Related operation on provider with the id c38a67ec-0b48-4e6f-be85-70c700df5483 is currently in progress. Please try again later.]2018-03-15 10:05:00,254-04 DEBUG [org.ovirt.engine.core.utils.servlet.LocaleFilter] (default task-14) [] Incoming locale 'en-US'. Filter determined locale to be 'en-US'2018-03-15 10:05:00,254-04 DEBUG [org.ovirt.engine.core.sso.servlets.OAuthTokenServlet] (default task-14) [] Entered OAuthTokenServlet Query String: null, Parameters : password = ***, grant_type = password, scope = ovirt-app-api ovirt-ext=token-info:validate, username = admin@internal, </error>*

3 7

OST Failure - Weekly update [09/03/2018-16/03/2018]
by Dafna Ron 16 Mar '18

16 Mar '18

Hello, I would like to update on this week's failures and OST current status. We had a very eventful week with 2 regressions identified by OST 1. On 11-03-2018 the CI team reported a regression in project ovirt-engine. The change reported was https://gerrit.ovirt.org/#/c/88738/ - db: add func to turn table columns to empty string. This caused a failure in both master and 4.2 in OST but was also identified to be an issue in 4.1. The fix for all 3 versions can be tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=1554377 and was submitted on 15-03-2018. I hope that in future we would resolve such regression much faster as it took us 5 days to resolve this issue but I would also like to thank all that helped to resolve it once the issue was investigated more deeply. 2. on 13-03-2018 we found a regression in otopi: *core: Use python3 when possible- https://gerrit.ovirt.org/#/c/87276/ <https://gerrit.ovirt.org/#/c/87276/>* *The fix was* submitted *on the same day **https://gerrit.ovirt.org/88931 <https://gerrit.ovirt.org/88931> - **spec: Package otopi-functions* We also had 1 configuration related issue which was fixed by the CI team and we had failed build-artifacts, mostly in fc27. this was due to the change in fedora to not allow the use of yum and had to be solved by the projects making minor patch changes. *Below you can see the chart for this week's resolved issues but cause of failure:*Code = regression of working components/functionalities Configurations = package related issues Other = failed build artifacts Infra = infrastructure/OST/Lago related issues *Below is a chart of resolved failures based on ovirt version* *Below is a chart showing failures by suite type: * Thank you, Dafna

1 0

UI plugin API updates
by Vojtech Szocs 15 Mar '18

15 Mar '18

Dear community, the UI plugin API will be updated to reflect recent oVirt web administration UI design changes. The relevant patch is already merged in master branch [1] and the associated BZ [2] is targeted for 4.3 release. *What's new* Two new API functions, addPrimaryMenuContainer and addSecondaryMenuPlace, allow you to add custom secondary menu items to the vertical navigation menu. You can target both existing (core) and custom primary menu items when adding secondary ones. *What's changed* Some API functions were renamed to stay consistent with current UI design, i.e. reflecting the absence of "main" and "sub" tabs. - addMainTab => addPrimaryMenuPlace - addSubTab => addDetailPlace - setTabContentUrl => setPlaceContentUrl - setTabAccessible => setPlaceAccessible - addMainTabActionButton => addMenuPlaceActionButton - addSubTabActionButton => addDetailPlaceActionButton You can still use the original functions mentioned above, but doing so will yield a warning in the browser console, for example: *addMainTab is deprecated, please use addPrimaryMenuPlace instead.* In addition, for functions that used to deal with "main" or "sub" tabs, the options object no longer supports alignRight (boolean) parameter. That's because PatternFly tabs widget [3] expects all tabs to be aligned next to each other, flowing from left to right. We'll be updating the UI plugins feature page shortly to reflect all the changes. [1] https://gerrit.ovirt.org/#/c/88690/ [2] https://bugzilla.redhat.com/1553902 [3] http://www.patternfly.org/pattern-library/widgets/#tabs Regards, Vojtech

1 0