June 2019 - Devel - oVirt List Archives

GetDeviceList and direct LUNs
by Fedor Gavrilov 11 Jun '19

11 Jun '19

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

2 5

vdsm has been tagged (v4.30.19)
by Milan Zamazal 11 Jun '19

11 Jun '19

2 1

vdsm has been tagged (v4.30.18)
by Milan Zamazal 11 Jun '19

11 Jun '19

1 0

ovirt-engine has been tagged (ovirt-engine-4.3.5)
by Tal Nisan 11 Jun '19

11 Jun '19

1 0

Re: oVirt survey - May 2019
by Sandro Bonazzola 10 Jun '19

10 Jun '19

Il giorno lun 20 mag 2019 alle ore 13:30 Sandro Bonazzola < sbonazzo(a)redhat.com> ha scritto: > As we continue to develop oVirt 4.3 and future releases, the Development > and Integration teams at Red Hat would value insights on how you are > deploying the oVirt environment. > Please help us to hit the mark by completing this short survey. Survey > will close on June 7th. > If you're managing multiple oVirt deployments with very different use > cases or very different deployments you can consider answering this survey > multiple times. > Please note the answers to this survey will be publicly accessible. This > survey is under oVirt Privacy Policy available at > https://www.ovirt.org/site/privacy-policy.html > > The survey is available here: https://forms.gle/8uzuVNmDWtoKruhm8 > > The Survey is now closed Results are available here: https://docs.google.com/forms/d/e/1FAIpQLSdBoN2otjkxzJdsdmldpjg5tRl9aqg2vOF… Thanks everyone who participated to the survey! -- 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>

1 0

planned gerrit downtime
by Evgheni Dereveanchin 10 Jun '19

10 Jun '19

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

3 4

FC28 Blacklisted in oVirt STDCI V2
by Barak Korren 10 Jun '19

10 Jun '19

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

1 0

cannot add host (oVirt 4.3.3.7)
by Hetz Ben Hamo 09 Jun '19

09 Jun '19

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>

1 0

[Ovirt] [CQ weekly status] [07-06-2019]
by Dafna Ron 07 Jun '19

07 Jun '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 (#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-qu… [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.3_change-q… [3] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change… 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)

1 0

Master is broken for Fedora
by Sandro Bonazzola 05 Jun '19

05 Jun '19

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/vdsm-… /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>

3 10