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
3 years, 7 months
Vdsm: Intention to make ovirt-4.3 branch
by Milan Zamazal
Hi, I'm going to make ovirt-4.3 Vdsm branch next week.
If there are any very important reasons not to make it, please let me
know.
Thanks,
Milan
5 years, 9 months
[VDSM] Flaky protocol detector test
by Nir Soffer
Recently this test cause too many random failures. I guess this is
the known issue with handling SUBSCRIBE in protocol detector.
I posted https://gerrit.ovirt.org/c/97099/
To mark it as broken until we have time to dig deeper
======================================================================
FAIL: test_detect_slow_client_concurrency(True)
(protocoldetector_test.AcceptorTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/testlib.py",
line 142, in wrapper
return f(self, *args)
File "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/protocoldetector_test.py",
line 167, in test_detect_slow_client_concurrency
self.check_concurrently(self.check_slow_client, use_ssl)
File "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/protocoldetector_test.py",
line 266, in check_concurrently
self.assertTrue(all(done))
AssertionError: False is not true
-------------------- >> begin captured logging << --------------------
2019-01-19 20:47:16,021 DEBUG (MainThread) [vds.MultiProtocolAcceptor]
Creating socket (host='127.0.0.1', port=0, family=2, socketype=1,
proto=6) (protocoldetector:225)
2019-01-19 20:47:16,022 INFO (MainThread) [vds.MultiProtocolAcceptor]
Listening at 127.0.0.1:46009 (protocoldetector:183)
2019-01-19 20:47:16,023 DEBUG (MainThread) [vds.MultiProtocolAcceptor]
Adding detector <protocoldetector_test.Echo object at 0x7f1bb77f8dd0>
(protocoldetector:210)
2019-01-19 20:47:16,024 DEBUG (MainThread) [vds.MultiProtocolAcceptor]
Adding detector <protocoldetector_test.Uppercase object at
0x7f1bb77f8c90> (protocoldetector:210)
2019-01-19 20:47:16,031 INFO (Thread-61)
[ProtocolDetector.AcceptorImpl] Accepted connection from
127.0.0.1:51950 (protocoldetector:61)
2019-01-19 20:47:16,047 INFO (Thread-61)
[ProtocolDetector.AcceptorImpl] Accepted connection from
127.0.0.1:51952 (protocoldetector:61)
2019-01-19 20:47:16,048 INFO (Thread-61)
[ProtocolDetector.AcceptorImpl] Accepted connection from
127.0.0.1:51954 (protocoldetector:61)
2019-01-19 20:47:16,065 INFO (Thread-61)
[ProtocolDetector.AcceptorImpl] Accepted connection from
127.0.0.1:51956 (protocoldetector:61)
2019-01-19 20:47:16,068 INFO (Thread-61)
[ProtocolDetector.AcceptorImpl] Accepted connection from
127.0.0.1:51958 (protocoldetector:61)
2019-01-19 20:47:16,069 DEBUG (Thread-61) [ProtocolDetector.Detector]
Using required_size=9 (protocoldetector:89)
2019-01-19 20:47:16,097 DEBUG (Thread-61) [ProtocolDetector.Detector]
Using required_size=9 (protocoldetector:89)
2019-01-19 20:47:16,099 DEBUG (Thread-61) [ProtocolDetector.Detector]
Using required_size=9 (protocoldetector:89)
2019-01-19 20:47:16,107 DEBUG (Thread-61) [ProtocolDetector.Detector]
Using required_size=9 (protocoldetector:89)
2019-01-19 20:47:16,109 DEBUG (Thread-61) [ProtocolDetector.Detector]
Using required_size=9 (protocoldetector:89)
2019-01-19 20:47:16,574 INFO (Thread-61) [ProtocolDetector.Detector]
Detected protocol echo from 127.0.0.1:51950 (protocoldetector:125)
2019-01-19 20:47:17,570 DEBUG (Thread-61) [ProtocolDetector.Detector]
Timed out while waiting for data (protocoldetector:94)
2019-01-19 20:47:17,571 DEBUG (Thread-61) [ProtocolDetector.Detector]
Timed out while waiting for data (protocoldetector:94)
2019-01-19 20:47:17,576 DEBUG (Thread-61) [ProtocolDetector.Detector]
Timed out while waiting for data (protocoldetector:94)
2019-01-19 20:47:17,578 DEBUG (Thread-61) [ProtocolDetector.Detector]
Timed out while waiting for data (protocoldetector:94)
--------------------- >> end captured logging << ---------------------
5 years, 9 months
propose Ravi Nori as a frontend maintainer for ovirt-engine infra
by Greg Sheremeta
Hi all,
I'd like to propose Ravi Nori as a frontend maintainer for ovirt-engine
infra team. While the infra team typically hasn't had a frontend
maintainer, Ravi has strong knowledge of all of the frontend infra pieces,
including everything related to SSO, welcome page, and GWT in admin portal.
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>
5 years, 9 months
oVirt on Fedora 28 status update
by Nir Soffer
Last time we discussed this here, we had only sanlock issue:
https://bugzilla.redhat.com/1593853
The bug was fixed upstream about 2 month ago, but the Fedora package was
not available.
The package is not available yet in Fedora, but we have a build here:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1182539
You can install sanlock from this build using:
dnf upgrade
https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/...
\
https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/...
\
https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/...
Hopefully the package will pushed soon to updates-testing repo.
With this you can use enable selinux as god intended.
But if you update your host to kernel 4.20.4-100, multipath is broken. All
multipath devices
are not available, and your hosts will probably become non-operational
since they report the
iSCSI/FC storage domains in problem.
The issue was reported here:
https://lkml.org/lkml/2018/11/5/398
And we have this Fedora 29 bug:
https://bugzilla.redhat.com/1669235
Ben explains it is:
The kernel is switching over to use block multiqueue instead of the old
request
queue. Part of doing this is removing support for the old request queue
from device-mapper. Another part is to remove support for the old
request queue from the scsi layer. For some reason, the first part got
into this fedora kernel, but the second part didn't. It seems to me
that since the fedora kernel has removed support for non-blk-mq based
devices,
I should have been compiled with CONFIG_SCSI_MQ_DEFAULT=y
To fix this issue you need to add the scsi_mod.use_blk_mq=Y option to the
kernel command line:
grubby --args=scsi_mod.use_blk_mq=Y --update-kernel
/boot/vmlinuz-4.20.4-100.fc28.x86_64
After reboot, your multipath devices will appear again.
Cheers,
Nir
5 years, 9 months
Planned infra outage - Saturday February 2
by Evgheni Dereveanchin
Hi everyone,
There's a maintenance window planned for this Saturday, February 2 2019 to
upgrade network equipment in the PHX datacenter. The change will be
implemented during afternoon hours and several oVirt infra services may be
unreachable for short periods of time, specifically:
* package repositories
* Jenkins CI
* glance image repo
If you have problems accessing project resources during this period or see
CI failures please re-try in a couple of hours.
The project website and Gerrit code review are not affected by this outage
and will continue to function normally.
--
Regards,
Evgheni Dereveanchin
5 years, 10 months
