GetDeviceList and direct LUNs
by Fedor Gavrilov
Hi,
I want to implement a feature that would allow one to manually refresh sizes for direct LUNs and I am not sure if existing code in the engine codebase is gonna help with that.
RefreshLunsSizeCommand seems to be doing what is needed, but it operates on a premise that LUNs to refresh belong to a storage domain which makes most of its code irrelevant for purposes of direct LUNs.
It seems that workhorse is GetDeviceList command, but from the code I can't quite understand if it's supposed to be used with external iSCSI targets. Especially 'VDS' part here confuses me since I am not sure what VDS we're talking about in the first place when using direct LUN.
If GetDeviceList is of no use, is there anything else VDSM provides?
Thanks,
Fedor Gavrilov
4 years, 11 months
planned gerrit downtime
by Evgheni Dereveanchin
Hi everyone,
I will be migrating gerrit.ovirt.org to a different VM tonight so it will
be unavailable for several hours as the process involves copying large
amounts of data.
It will not be possible to pull from or push to any repos as well as to
review changes.
I'll follow up as soon as the migration is complete.
--
Regards,
Evgheni Dereveanchin
4 years, 11 months
FC28 Blacklisted in oVirt STDCI V2
by Barak Korren
Hi all,
By Snadro's request, as of a few minutes ago FC28 had been blacklisted in
oVirt's STDCI V2 system.
What this means is that if any project has FC28 threads configured in its
STDCI V2 YAML configuration file, those threads will be ignored by the
STDCI system and not invoked.
Threads for building and testing on other distributions will keep working
as before.
It is still recommended that projects with fc28 configuration will patch
their configuration files to remove FC28, to make it easier to understand
what the CI does and not rely on an implicit blacklist.
Please note that this only concerns projects that have made the switch to
STDCI V2. Projects that still use V1, and have FC28 jobs defined, those
jobs will keep working as before. The following patch by Sandro, however,
includes code to remove all those jobs:
https://gerrit.ovirt.org/c/100556/
Thanks,
Barak.
--
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
4 years, 11 months
cannot add host (oVirt 4.3.3.7)
by Hetz Ben Hamo
Hi,
I'm trying to add a new host to oVirt. The main host is Xeon E5 while the
new host is AMD Ryzen 5.
The main host is running oVirt 4.3.3 and the new node is a minimal install
of CentOS 7.6 (1810) with all the latest updates.
I'm enclosing the log files. it complains that it cannot get the oVirt
packages, perhaps wrong channel(?). Looking at the log, it's trying to use
minidnf. I don't think CentOS 7 supports DNF..
Thanks
Hetz
תודה,
*חץ בן חמו*
אתם מוזמנים לבקר בבלוג היעוץ <http://linvirtstor.net/> או בבלוג הפרטי שלי
<http://benhamo.org>
4 years, 11 months
[Ovirt] [CQ weekly status] [07-06-2019]
by Dafna Ron
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 failure was on 05-06 for project ovirt-ansible-cluster-upgrade due to
failure in test 002_bootstrap.add_master_storage_domain.
The fix was created and merged <https://gerrit.ovirt.org/#/c/100089/>
*CQ-4.3*: RED (#1)
vdsm is currently broken due to https://gerrit.ovirt.org/#/c/100576/ -
Remove SOS VDSM plugin
vdsm sos plugin will be available from centos 7.7 as part of sos-3.7-3.
however, the metrics tests are using sos-logcollector which s causing a
failure in ost.
We are waiting for Shirly to have a look at the tests and see how they can
be fixed.
*CQ-Master:* RED (#1)
vdsm is currently broken due to https://gerrit.ovirt.org/#/c/100576/ -
Remove SOS VDSM plugin
vdsm sos plugin will be available from centos 7.7 as part of sos-3.7-3.
however, the metrics tests are using sos-logcollector which s causing a
failure in ost.
We are waiting for Shirly to have a look at the tests and see how they can
be fixed.
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-...
[2]
https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.3_change...
[3]
http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_chan...
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)
4 years, 11 months
Master is broken for Fedora
by Sandro Bonazzola
Hi,
just to let you know that vdsm jsut broke hosted engine on fedora.
Reason is that hosted engine is still building for python2 whiile vdsm is
now being shipped for python3 only.
hosted engine build is currently broken on missing yajsonrpc being:
$ rpm -ql
https://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc28/noarch/vds...
/usr/lib/python3.6/site-packages/yajsonrpc/__pycache__/betterAsyncore.cpython-36.opt-1.pyc
/usr/lib/python3.6/site-packages/yajsonrpc/__pycache__/betterAsyncore.cpython-36.pyc
/usr/lib/python3.6/site-packages/yajsonrpc/__pycache__/exception.cpython-36.opt-1.pyc
/usr/lib/python3.6/site-packages/yajsonrpc/__pycache__/exception.cpython-36.pyc
/usr/lib/python3.6/site-packages/yajsonrpc/__pycache__/stomp.cpython-36.opt-1.pyc
/usr/lib/python3.6/site-packages/yajsonrpc/__pycache__/stomp.cpython-36.pyc
/usr/lib/python3.6/site-packages/yajsonrpc/__pycache__/stompclient.cpython-36.opt-1.pyc
/usr/lib/python3.6/site-packages/yajsonrpc/__pycache__/stompclient.cpython-36.pyc
/usr/lib/python3.6/site-packages/yajsonrpc/__pycache__/stompserver.cpython-36.opt-1.pyc
/usr/lib/python3.6/site-packages/yajsonrpc/__pycache__/stompserver.cpython-36.pyc
/usr/lib/python3.6/site-packages/yajsonrpc/betterAsyncore.py
/usr/lib/python3.6/site-packages/yajsonrpc/exception.py
/usr/lib/python3.6/site-packages/yajsonrpc/stomp.py
/usr/lib/python3.6/site-packages/yajsonrpc/stompclient.py
/usr/lib/python3.6/site-packages/yajsonrpc/stompserver.py
please note that package naming for this package is not following Fedora
guidelines. It should be prefixed with "python3-" according to
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_naming
Rule doesn't apply to applications but yajsonrpc subpackage is a library
package.
--
Sandro Bonazzola
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo(a)redhat.com
<https://red.ht/sig>
<https://redhat.com/summit>
4 years, 11 months
