Error Java SDK Issue??
by Geschwentner, Patrick
Dear Ladies and Gentlemen!
I am currently working with the java-sdk and I encountered a problem.
If I would like to retrieve the disk details, I get the following error:
Disk currDisk = ovirtConnection.followLink(diskAttachment.disk());
The Error is occurring in this line:
[cid:image001.png@01D44537.AF127FD0]
The getResponst looks quiet ok. (I inspected: [cid:image002.png@01D44537.AF127FD0] and it looks ok).
Error:
wrong number of arguments
The code is quiet similar to what you published on github (https://github.com/oVirt/ovirt-engine-sdk-java/blob/master/sdk/src/test/j... ).
Can you confirm the defect?
Best regards
Patrick
2 years, 1 month
Python 3 vdsm RPM packages
by Marcin Sobczyk
Hi,
On yesterday's vdsm weekly call, we were discussing the need of making
Python 3 vdsm RPM packages.
Some facts:
- it doesn't make a lot sense to spend much time on trying to package
everything - it's completely impossible i.e. to run vdsm without having
'sanlock' module
- our current vdsm.spec file is crap
Two non-exclusive propositions were raised:
- let's try to make a quick-and-dirty patch, that will completely
overwrite the existing 'vdsm.spec' (effectively making it Python 3-only)
for testing purposes, and maintain it for a while
- in the meantime, let's write a completely new, clean and beautiful
spec file in an package-by-package, incremental manner, (also Python
3-only) that would eventually substitute the original one
The quick-and-dirty spec file would be completely unsupported by CI. The
new one would get a proper CI sub-stage in 'build-artifacts' stage.
The steps needed to be done are:
- prepare autotools/Makefiles to differentiate Python 2/Python 3 RPM builds
- prepare the new spec file (for now including only 'vdsm-common' package)
- split 'build-artifacts' stage into 'build-py27' and 'build-py36'
sub-stages (the latter currently running on fc28 only)
The only package we can start with, when making the new spec file, is
'vdsm-common', as it doesn't depend on anything else (or at least I hope
so...).
There were also propositions about how to change the new spec file in
regard to the old one (like making 'vdsm' package a meta-package). This
is a good time for these propositions to be raised, reviewed and
documented (something like this maybe?
https://docs.google.com/document/d/13EXN1Iwq-OPoc2A5Y3PJBpOiNC10ugx6eCE72...),
so we can align the new spec file as we build it.
I can lay the groundwork by doing the autotools/Makefiles and
'build-artifacts' splitting. Gal Zaidman agreed on starting to work on
the new spec file. Milan mentioned, that he had something like the
quick-and-dirty patch, maybe he can share it with us.
Questions, comments are welcome.
Regards, Marcin
4 years, 1 month
[ OST Failure Report ] [ oVirt Master (ovirt-engine-nodejs-modules) ] [ 27-02-2019 ] [ 002_bootstrap.add_vm2_lease ]
by Dafna Ron
Hi,
We have a failure on the project in basic suite, master branch. The recent
failure was in patch:
https://gerrit.ovirt.org/#/c/98087/1 - Add pre-seed for ovirt-web-ui
CQ is pointing at the below as the root cause (which was merged a while
back):
https://gerrit.ovirt.org/#/c/97491/ - Add pre-seed for ovirt-web-ui
Can you please check the issue as it seems both patches are changing the
same thing and the project seem to be broken since
https://gerrit.ovirt.org/#/c/97491/3
Latest failure:
https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13171/
Logs:
https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13171/arti...
errors from logs:
Engine:
2019-02-27 13:37:28,479-05 ERROR
[org.ovirt.engine.core.bll.UpdateVmCommand] (default task-1) [74283e25]
Transaction rolled-back for command
'org.ovirt.engine.core.bll.UpdateVmCommand'.
2019-02-27 13:37:28,483-05 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-1) [74283e25] EVENT_ID: USER_FAILED_UPDATE_VM(58), Failed to
update VM vm2 (User: admin@inter
nal-authz).
2019-02-27 13:37:28,485-05 INFO
[org.ovirt.engine.core.bll.UpdateVmCommand] (default task-1) [74283e25]
Lock freed to object 'EngineLock:{exclusiveLocks='[vm2=VM_NAME]',
sharedLocks='[3500eb82-e5e2-4e24-b41c-ea
02d9f6adee=VM]'}'
2019-02-27 13:37:28,485-05 DEBUG
[org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
(default task-1) [74283e25] method: runAction, params: [UpdateVm,
VmManagementParametersBase:{commandId='340
59769-05b9-429e-8356-f6b9b9953f55', user='admin', commandType='UpdateVm',
vmId='3500eb82-e5e2-4e24-b41c-ea02d9f6adee'}], timeElapsed: 6618ms
2019-02-27 13:37:28,486-05 ERROR
[org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default
task-1) [] Operation Failed: []
2019-02-27 13:37:28,579-05 DEBUG
[org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
(EE-ManagedThreadFactory-engineScheduled-Thread-85) [] method: get, params:
[e29c0ba1-464c-4eb4-a8f2-c6933d9
9969a], timeElapsed: 3ms
vdsm:
2019-02-27 13:37:21,987-0500 INFO (jsonrpc/1) [vdsm.api] FINISH lease_info
error=No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee
from=::ffff:192.168.201.4,43920,
flow_id=117dec74-ad59-4b12-8148-b2c130337c10,
task_id=9c297d41-0aa7-4c74-b268-b710e666bc6c (api:52)
2019-02-27 13:37:21,988-0500 ERROR (jsonrpc/1) [storage.TaskManager.Task]
(Task='9c297d41-0aa7-4c74-b268-b710e666bc6c') Unexpected error (task:875)
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882,
in _run
return fn(*args, **kargs)
File "<string>", line 2, in lease_info
File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 50, in
method
ret = func(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 3702,
in lease_info
info = dom.lease_info(lease.lease_id)
File "/usr/lib/python2.7/site-packages/vdsm/storage/sd.py", line 674, in
lease_info
return vol.lookup(lease_id)
File "/usr/lib/python2.7/site-packages/vdsm/storage/xlease.py", line 553,
in lookup
raise NoSuchLease(lease_id)
NoSuchLease: No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee
2019-02-27 13:37:21,988-0500 INFO (jsonrpc/1) [storage.TaskManager.Task]
(Task='9c297d41-0aa7-4c74-b268-b710e666bc6c') aborting: Task is aborted:
u'No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee' - code 100
(task:1181)
2019-02-27 13:37:21,988-0500 ERROR (jsonrpc/1) [storage.Dispatcher] FINISH
lease_info error=No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee
(dispatcher:87)
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/vdsm/storage/dispatcher.py", line
74, in wrapper
result = ctask.prepare(func, *args, **kwargs)
File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 108,
in wrapper
return m(self, *a, **kw)
File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 1189,
in prepare
raise self.error
NoSuchLease: No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee
4 years, 2 months
Please don't remove instance type
by Baptiste Agasse
Hi all,
We are happy oVirt users for some years now (we started with 3.6, now on 4.2) and we manage most of our virtualization stacks with it. To provision and manage our machines, we use the foreman (for bare metal and virtual machines) on top of it. I made some little contributions to the foreman and other underlying stuff to have a deeper integration with oVirt, like to be able to select instance type directly from foreman interface/api and we rely on it. We use instance types to standardize our vms by defining system resources (memory, cpu and cpu topology) console type, boot options. On top of that we plan to use templates to apply OS (CentOS 7 and CentOS 6 actually). Having resources definitions separated from OS installation help us to keep instance types and templates lists small and don't bother users about some technical underlying stuff. As we are interested in automating oVirt maintenance tasks and configuration with ansible, I asked at FOSDEM oVirt booth if there is any ansible module to manage instance types in Ovirt as I didn't find it in ovirt ansible infra repo. The person to whom I asked the question said that you are planning to remove instance types from ovirt, and this make me sad :(. So here I am to ask why do you plan to remove instance types from oVirt. As far as I know, it's fairly common to have "instance types" / "flavors" / "sizes" on one side and then templates (bare OS, preinstalled appliances...) on other side and pick one of each to make an instance. If this first part is missing in future version of ovirt, it will be a pain point for us. So, my question is, do you really plan to remove instances type definitely ?
Cheers.
--
Baptiste
4 years, 2 months
oVirt documentation vs. feature pages
by Greg Sheremeta
Hi,
TL;DR: please don't direct users to feature pages -- direct them to
end-user documentation instead. And maintain content separation between
end-user documentation and technical docs like feature pages.
...
Lately we've cleaned up documentation on ovirt.org, and I wanted to share
some of my thoughts about it. As a user experience focused person, I really
believe that clear and helpful documentation is crucial to the project's
success. I've also seen outdated documentation be a source of extreme
frustration for our users.
In the distant past, most of oVirt's documentation was written by
developers on a wiki, typically in the form of "feature pages." Feature
pages are basically technical design documents with occasionally some user
help sprinkled in.
With oVirt 4.0, we put a great set of clear documentation, written by
technical writers, on the oVirt website (which was also converted from a
wiki to a regular static site). This documentation is up to date with 4.2,
and we'll get the 4.3 content out there soon.
This official documentation lives at https://ovirt.org/documentation
and it should be considered the authoritative place for users to access our
documentation.
Feature pages, on the other hand, are (now) for developers. When you hear
the term "feature page", think "technical design document." Most users
should not be interested in this content.
It helps to think about the personas.
1. oVirt admins -- the person who sets up oVirt on Day 1 and 2. This is the
person who cares about and will read the Installation Guide and the
Administration Guide. These live under /documentation, e.g.
https://ovirt.org/documentation/install-guide/Installation_Guide.html
2. oVirt users -- the people who use oVirt to create, manage, and use
virtual machines, etc. This person will care about and read the VM Portal
Guide, User Guides, and such. These also live under /documentation, e.g.
https://ovirt.org/documentation/vmm-guide/Virtual_Machine_Management_Guid...
3. Developers -- you and I, and occasionally highly curious and technical
admins. These people might care about how the project works under the hood
-- high level designs, code flows, etc. Persona 2, oVirt users, do not care
about these details when they are learning to use oVirt, so end-user
documentation should not be polluted with this type of content. This
content now lives exclusively under /develop, the developer's section of
the site.
https://ovirt.org/develop/release-management/features/
Let's help our users by directing them to the end-user documentation, not
to feature pages. If you would like to contribute end-user documentation,
it should go under /documentation and not in a feature page. If you build a
new feature, the technical stuff goes under
/develop/release-management/features/ and the end-user stuff goes under
/documentation.
Feedback welcome :)
Best wishes,
Greg
--
GREG SHEREMETA
SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
Red Hat NA
<https://www.redhat.com/>
gshereme(a)redhat.com IRC: gshereme
<https://red.ht/sig>
4 years, 2 months
Can't discover luns on iscisi target when host is running fedora 28
by Fedor Gavrilov
Hi,
Recently I hit an issue when I can't add iscsi storage domain because engine can't see any LUNs there. I wonder if I missed some step in the configuration or something.
There is a fedora 29 machine running iscsi target which has a single lun and host (banana) registered in its ACL:
[cucumber@cucumber ~]$ sudo targetcli
[sudo] password for cucumber:
targetcli shell version 2.1.fb48
Copyright 2011-2013 by Datera, Inc and others.
For help on commands, type 'help'.
/iscsi/iqn.20...e:target/tpg1> ls
o- tpg1 ..................................................................................................... [no-gen-acls, no-auth]
o- acls ................................................................................................................ [ACLs: 1]
| o- iqn.1994-05.com.redhat:4bf5ff1a15b6 ........................................................................ [Mapped LUNs: 1]
| o- mapped_lun0 ................................................................................. [lun0 fileio/filestore0 (rw)]
o- luns ................................................................................................................ [LUNs: 1]
| o- lun0 ................................................................... [fileio/filestore0 (/etc/fileio) (default_tg_pt_gp)]
o- portals .......................................................................................................... [Portals: 1]
o- 0.0.0.0:3260 ........................................................................................................... [OK]
From fedora 28 host I can login and logout, but there is this segfault and when I try getting LUN info it fails:
[banana@banana ~]$ sudo iscsiadm --mode discovery --type sendtargets --portal cucumber
192.168.111.4:3260,1 iqn.2016-01.com.example:target
[banana@banana ~]$ sudo iscsiadm -m node -T iqn.2016-01.com.example:target -l
Logging in to [iface: default, target: iqn.2016-01.com.example:target, portal: 192.168.111.4,3260] (multiple)
Login to [iface: default, target: iqn.2016-01.com.example:target, portal: 192.168.111.4,3260] successful.
[banana@banana ~]$ sudo iscsiadm -m session -P 3 -r 2
iscsiadm: could not read session targetname: 5
iscsiadm: Could not get session info for sid 2
[banana@banana ~]$ sudo iscsiadm -m session -P 3
iSCSI Transport Class version 2.0-870
version 6.2.0.874
Segmentation fault
It seems I am hitting this: https://bugzilla.redhat.com/show_bug.cgi?id=1462767
Could this be the reason that there are no LUNs in engine web UI after I discover iscsi target? Is anyone aware of workaround or whether I am doing something wrong?
Thanks,
Fedor Gavrilov
4 years, 2 months
[ OST Failure Report ] [ oVirt Master ] [ 27-02-2019 ] [ 002_bootstrap.get_host_devices]
by Galit Rosenthal
Hi,
we are failing basic suite master (vdsm, ovirt-engine-sdk ...)
It happens sporadically.
We disqualify that this is an infra issue.
Can you please have a look at the issue?
ERROR:
<testcase classname="002_bootstrap" name="get_host_devices" time="0.077">
<error type="exceptions.RuntimeError" message="*Could not find
block_vda_1 device in host devices*: "><![CDATA[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-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py",
line 1016, in get_host_devices
raise RuntimeError('Could not find block_vda_1 device in host
devices: {}'.format(device_list))
RuntimeError: Could not find block_vda_1 device in host devices:
]]></error>
Thanks,
Galit
Examples, Full logs:
[1] https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/ovirt...
[2]
https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/ovirt...
_______________________________________________
Infra mailing list -- infra(a)ovirt.org
To unsubscribe send an email to infra-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/infra@ovirt.org/message/WXW6II3NYEX...
--
GALIT ROSENTHAL
SOFTWARE ENGINEER
Red Hat
<https://www.redhat.com/>
galit(a)gmail.com T: 972-9-7692230
<https://red.ht/sig>
4 years, 2 months
[ OST Failure Report ] [ oVirt Master (ovirt-engine) ] [ 28-02-2019 ] [ 002_bootstrap.resize_and_refresh_storage_domain ]
by Dafna Ron
Hi,
The test failed due to not finding master storage domain
I am seeing a build of engine that passed so its possible that this is
related to the random failures we have been having on other tests but since
the change reported is storage related, can you please review the logs to
see if anything happened to the master domain while trying to resize?
CQ reported this change as root cause:
https://gerrit.ovirt.org/#/c/98015/6 - blockSD: Move legacy block size
constants to sd
build failure:
https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13175/
logs:
https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13175/arti...
errors in log:
2019-02-27 17:35:02,222-05 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(EE-ManagedThreadFactory-engine-Thread-23) [558e4473] EVENT_ID:
VDS_BROKER_COMMAND_FAILURE(10,802), VDSM la
go-basic-suite-master-host-1 command ConnectStoragePoolVDS failed: Cannot
find master domain: u'spUUID=1c79b83e-32d6-43e0-bc61-2955e42c3a58,
msdUUID=7a7e1d7b-08aa-49f6-bdf2-4be64260b5a9'
2019-02-27 17:35:02,222-05 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand]
(EE-ManagedThreadFactory-engine-Thread-23) [558e4473] Command
'org.ovirt.engine.core.vdsbroker.vdsbroker.
ConnectStoragePoolVDSCommand' return value 'StatusOnlyReturn [status=Status
[code=304, message=Cannot find master domain:
u'spUUID=1c79b83e-32d6-43e0-bc61-2955e42c3a58,
msdUUID=7a7e1d7b-08aa-49f6-bdf2-4be64260b5
a9']]'
2019-02-27 17:35:02,222-05 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand]
(EE-ManagedThreadFactory-engine-Thread-23) [558e4473] HostName =
lago-basic-suite-master-host-1
2019-02-27 17:35:02,223-05 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand]
(EE-ManagedThreadFactory-engine-Thread-23) [558e4473] Command
'ConnectStoragePoolVDSCommand(HostName = lago-basic-suite-master-host-1,
ConnectStoragePoolVDSCommandParameters:{hostId='1ac0eda2-0980-40df-b029-b262680696a4',
vdsId='1ac0eda2-0980-40df-b029-b262680696a4',
storagePoolId='1c79b83e-32d6-43e0-bc61-2955e42c3a58', masterVersion='1'})'
execution failed: IRSGenericException: IRSErrorException:
IRSNoMasterDomainException: Cannot find master domain:
u'spUUID=1c79b83e-32d6-43e0-bc61-2955e42c3a58,
msdUUID=7a7e1d7b-08aa-49f6-bdf2-4be64260b5a9'
2019-02-27 17:35:02,223-05 DEBUG
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand]
(EE-ManagedThreadFactory-engine-Thread-23) [558e4473] Exception:
org.ovirt.engine.core.vdsbroker.irsbroker.IRSNoMasterDomainException:
IRSGenericException: IRSErrorException: IRSNoMasterDomainException: Cannot
find master domain: u'spUUID=1c79b83e-32d6-43e0-bc61-2955e42c3a58,
msdUUID=7a7e1d7b-08aa-49f6-bdf2-4be64260b5a9'
at
org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase.proceedProxyReturnValue(BrokerCommandBase.java:50)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand.proceedConnectProxyReturnValue(ConnectStoragePoolVDSCommand.java:48)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand.proceedProxyReturnValue(ConnectStoragePoolVDSCommand.java:36)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand.executeVdsBrokerCommand(ConnectStoragePoolVDSCommand.java:32)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVdsCommandWithNetworkEvent(VdsBrokerCommand.java:123)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:111)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:65)
[vdsbroker.jar:]
at
org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:31)
[dal.jar:]
at
org.ovirt.engine.core.vdsbroker.vdsbroker.DefaultVdsCommandExecutor.execute(DefaultVdsCommandExecutor.java:14)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.ResourceManager.runVdsCommand(ResourceManager.java:396)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.ResourceManager$Proxy$_$$_WeldSubclass.runVdsCommand$$super(Unknown
Source) [vdsbroker.jar:]
at sun.reflect.GeneratedMethodAccessor252.invoke(Unknown Source)
[:1.8.0_191]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.8.0_191]
at java.lang.reflect.Method.invoke(Method.java:498)
[rt.jar:1.8.0_191]
at
org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:51)
[weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
at
org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:78)
[weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
at
org.ovirt.engine.core.common.di.interceptor.LoggingInterceptor.apply(LoggingInterceptor.java:12)
[common.jar:]
at sun.reflect.GeneratedMethodAccessor61.invoke(Unknown Source)
[:1.8.0_191]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.8.0_191]
at java.lang.reflect.Method.invoke(Method.java:498)
[rt.jar:1.8.0_191]
at
org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
[weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
at
org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84)
[weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
at
org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72)
[weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
at
org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56)
[weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
at
org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79)
[weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
at
org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68)
[weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
at
org.ovirt.engine.core.vdsbroker.ResourceManager$Proxy$_$$_WeldSubclass.runVdsCommand(Unknown
Source) [vdsbroker.jar:]
at
org.ovirt.engine.core.bll.storage.pool.RefreshPoolSingleAsyncOperation.execute(RefreshPoolSingleAsyncOperation.java:59)
[bll.jar:]
at
org.ovirt.engine.core.utils.SynchronizeNumberOfAsyncOperations$AsyncOpThread.call(SynchronizeNumberOfAsyncOperations.java:43)
[utils.jar:]
at
org.ovirt.engine.core.utils.SynchronizeNumberOfAsyncOperations$AsyncOpThread.call(SynchronizeNumberOfAsyncOperations.java:32)
[utils.jar:]
at
org.ovirt.engine.core.utils.threadpool.ThreadPoolUtil$InternalCallable.call(ThreadPoolUtil.java:117)
[utils.jar:]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[rt.jar:1.8.0_191]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[rt.jar:1.8.0_191]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[rt.jar:1.8.0_191]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_191]
at
org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
[javax.enterprise.concurrent-1.0.jar:]
4 years, 2 months
OST manual: enable engine 4.3
by Nir Soffer
When starting manual OST job, we can select engine version.
The available options are:
- master
- 42
Since we have now 4.3 branch, we should be able to select 4.3 engine.
See attached screenshot.
4 years, 2 months
