June 2019 - Devel - oVirt List Archives

[VDSM] Started getting virNetTLSContextCheckCertTimes:154 : The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired
by Edward Haas 11 Jan '24

11 Jan '24

Hi, I have a VM which acts as an oVirt host with VDSM installed. I use it for testing without connecting it to Engine. Recently VDSM fails to come up and I see this error: Sep 26 17:58:18 localhost libvirtd: 2018-09-26 14:58:18.978+0000: 12176: error : virNetTLSContextCheckCertTimes:154 : The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired Any hint on how to generate or fetch a new certificate without the help of Engine? Thanks, Edy.

3 5

Error: Adding new Host to ovirt-engine
by Ahmad Khiet 14 Aug '23

14 Aug '23

Hi, Can't add new host to ovirt engine, because the following error: 2019-06-12 12:23:09,664 p=4134 u=engine | TASK [ovirt-host-deploy-facts : Set facts] ************************************* 2019-06-12 12:23:09,684 p=4134 u=engine | ok: [10.35.1.17] => { "ansible_facts": { "ansible_python_interpreter": "/usr/bin/python2", "host_deploy_vdsm_version": "4.40.0" }, "changed": false } 2019-06-12 12:23:09,697 p=4134 u=engine | TASK [ovirt-provider-ovn-driver : Install ovs] ********************************* 2019-06-12 12:23:09,726 p=4134 u=engine | fatal: [10.35.1.17]: FAILED! => {} MSG: The conditional check 'cluster_switch == "ovs" or (ovn_central is defined and ovn_central | ipaddr and ovn_engine_cluster_version is version_compare('4.2', '>='))' failed. The error was: The ipaddr filter requires python's netaddr be installed on the ansible controller The error appears to be in '/home/engine/apps/engine/share/ovirt-engine/playbooks/roles/ovirt-provider-ovn-driver/tasks/configure.yml': line 3, column 5, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be: - block: - name: Install ovs ^ here 2019-06-12 12:23:09,728 p=4134 u=engine | PLAY RECAP ********************************************************************* 2019-06-12 12:23:09,728 p=4134 u=engine | 10.35.1.17 : ok=3 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 whats missing!? Thanks -- Ahmad Khiet Red Hat <https://www.redhat.com/> akhiet(a)redhat.com M: +972-54-6225629 <https://red.ht/sig>

7 10

Error Java SDK Issue??
by Geschwentner, Patrick 02 Apr '21

02 Apr '21

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/jav… ). Can you confirm the defect? Best regards Patrick

6 11

OST's basic suite UI sanity tests optimization
by Marcin Sobczyk 07 Aug '19

07 Aug '19

Hi, _TL; DR_ Let's cut the running time of '008_basic_ui_sanity.py' by more than 3 minutes by sacrificing Firefox and Chrome screenshots in favor of Chromium. During the OST hackathon in Brno this year, I saw an opportunity to optimize basic UI sanity tests from basic suite. The way we currently run them, is by setting up a Selenium grid using 3 docker containers, with a dedicated network... that's insanity! (pun intended). Let's a look at the running time of '008_basic_ui_sanity.py' scenario (https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test…) 01:31:50 @ Run test: 008_basic_ui_sanity.py: 01:31:50 nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] 01:31:50 # init: 01:31:50 # init: Success (in 0:00:00) 01:31:50 # start_grid: 01:34:05 # start_grid: Success (in 0:02:15) 01:34:05 # initialize_chrome: 01:34:18 # initialize_chrome: Success (in 0:00:13) 01:34:18 # login: 01:34:27 # login: Success (in 0:00:08) 01:34:27 # left_nav: 01:34:45 # left_nav: Success (in 0:00:18) 01:34:45 # close_driver: 01:34:46 # close_driver: Success (in 0:00:00) 01:34:46 # initialize_firefox: 01:35:02 # initialize_firefox: Success (in 0:00:16) 01:35:02 # login: 01:35:11 # login: Success (in 0:00:08) 01:35:11 # left_nav: 01:35:29 # left_nav: Success (in 0:00:18) 01:35:29 # cleanup: 01:35:36 # cleanup: Success (in 0:00:06) 01:35:36 # Results located at /dev/shm/ost/deployment-basic-suite-master/008_basic_ui_sanity.py.junit.xml 01:35:36 @ Run test: 008_basic_ui_sanity.py: Success (in 0:03:45) Starting the Selenium grid takes 2:15 out of 3:35 of total running time! I've investigated a lot of approaches and came up with something like this: * install 'chromium-headless' package on engine VM * download 'chromedriver' and 'selenium hub' jar and deploy them in '/var/opt/' on engine's VM * run 'selenium.jar' on engine VM from '008_basic_ui_sanity.py' by using Lago's ssh * connect to the Selenium instance running on the engine in '008_basic_ui_sanity.py' * make screenshots This series of patches represent the changes: https://gerrit.ovirt.org/#/q/topic:selenium-on-engine+(status:open+OR+statu…. This is the new running time (https://jenkins.ovirt.org/view/oVirt system tests/job/ovirt-system-tests_manual/4195/): 20:13:26 @ Run test: 008_basic_ui_sanity.py: 20:13:26 nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] 20:13:26 # init: 20:13:26 # init: Success (in 0:00:00) 20:13:26 # make_screenshots: 20:13:27 * Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fdb6004f8d0>: Failed to establish a new connection: [Errno 111] Connection refused',)': /wd/hub 20:13:27 * Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fdb6004fa10>: Failed to establish a new connection: [Errno 111] Connection refused',)': /wd/hub 20:13:27 * Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fdb6004fb50>: Failed to establish a new connection: [Errno 111] Connection refused',)': /wd/hub 20:13:28 * Redirecting http://192.168.201.4:4444/wd/hub -> http://192.168.201.4:4444/wd/hub/static/resource/hub.html 20:14:02 # make_screenshots: Success (in 0:00:35) 20:14:02 # Results located at /dev/shm/ost/deployment-basic-suite-master/008_basic_ui_sanity.py.junit.xml 20:14:02 @ Run test: 008_basic_ui_sanity.py: Success (in 0:00:35) (The 'NewConnectionErrors' is waiting for Selenium hub to be up and running, I can silence these later). And the screenshots are here: https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… _The pros:_ * we cut the running time by more than 3 minutes _The cons:_ * we don't get Firefox or Chrome screenshots - we get Chromium screenshots (although AFAIK, QE has much more Selenium tests which cover both Firefox and Chrome) * we polute the engine VM with 'chromium-headless' package and deps (in total: 'chromium-headless', 'chromium-common', 'flac-libs' and 'minizip'), although we can remove these after the tests _Some design choices explained:_ Q: Why engine VM? A: Because the engine VM already has 'X11' libs. We could install 'chromium-headless' (and even other browsers) on our Jenkins executors, but that would mess them up a lot. Q: Why Chromium? A: Because it has a separate 'headless' package. Q: Why not use 'chromedriver' RPM in favor of https://chromedriver.storage.googleapis.com Chromedriver builds? A: Because the RPM version pulls a lot of extra dependencies even on the engine VM ('gtk3', 'cairo' etc.). Builds from the URL are the offical Google Chromedriver builds, they contain a single binary, and they work for us. _What still needs to be polished with the patches:_ * Currently 'setup_engine_selenium.sh' script downloads each time 'selenium.jar' and 'chromedriver.zip' (even with these downloads we get much faster set-up times) - we should bake these into the engine VM image template. * 'selenium_hub_running' function in 'selenium_on_engine.py' is hackish - an ability to run an ssh command with a context manager (and auto-terminate on it exits) should be part of Lago. Can be refactored. Questions, comments, reviews are welcome. Regards, Marcin

7 10

Successful 'vdsm-client Host getStats' call on py3
by Marcin Sobczyk 10 Jul '19

10 Jul '19

Hi, I'm currently working on making yajsonrpc/stomp implementation py3-compatible so we can have basic communication with vdsm running on py3. Today for the first time I was able to run vdsm [1] with py3 on fc29 and do a successful 'vdsm-client Host getStats' call. Since these patches are needed for other teams to continue with their work on py3, I'd kindly request those of you who are interested to review them: https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:p… https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:p… https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:p… https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:p… https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:p… https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:p… https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:p… [1] with minor tweak to 'storage.hsm' module

5 11

Proposing Andrej Krejcir as a maintainer of engine core
by Arik Hadas 02 Jul '19

02 Jul '19

Dear engine-core maintainers, I'd like to propose Andrej Krejcir as a maintainer of oVirt engine backend. Since Jul 2015, Andrej has been contributing to ovirt-engine, mostly in SLA areas (scheduling, quota, etc) and recently being more and more involved also in the VIRT areas. This results in ~200 patches to engine master alone. Personally, I reviewed some of Andrej's contributions and noticed reviews made by Andrej to others. I sincerely believe Andrej would be a good addition to the maintainers' group. Thanks in advance for your response!

7 6

Storage test case needs to be fixed: 002_bootstrap.resize_and_refresh_storage_domain
by Dafna Ron 02 Jul '19

02 Jul '19

Hi Tal, I am seeing random failures for test 002_bootstrap.resize_and_refresh_storage_domain It looks like this is a timing issue since by the time we print out the error we actually see the resize succeeded. see example below: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14185/testRep… Can you please assign someone from the storage team to fix this test? Thanks, Dafna

4 14

mom install error on fc29
by Miguel Duarte de Mora Barroso 01 Jul '19

01 Jul '19

Hi, I'm seeing the following error when I try to install ovirt-provider-ovn-driver (which requires vdsm): [MIRROR] mom-0.5.12-0.0.master.fc29.noarch.rpm: Interrupted by header callback: Server reports Content-Length: 340 but expected size is: 133356 17:13:50 [FAILED] mom-0.5.12-0.0.master.fc29.noarch.rpm: No more mirrors to try - All mirrors were already tried without success 17:13:50 Error: Error downloading packages: 17:13:50 Cannot download noarch/mom-0.5.12-0.0.master.fc29.noarch.rpm: All mirrors were tried Any clue ?.. it can be seen in [0]. Thanks in advance, Miguel [0] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-check-patch/2309/…

3 2

Getting "Could not fetch dashboard data. Please ensure that data warehouse is properly installed and configured" after upgrading RHV 4.2 to 4.3
by Lynn Dixon 30 Jun '19

30 Jun '19

I attempted to upgrade a hosted engine environment that was running RHV 4.2 to RHV 4.3 and everything appeared to have worked fine. Except when I login to the webui, I get the error in the dashboard that "Could not fetch dashboard data...." I see the dwhd service is running, and I noticed that there was a postgresql upgrade in the engine-setup, but I did not see any errors or oddness during the upgrade process. Is there something I am missing? *Lynn Dixon* | Red Hat Certified Architect #100-006-188 *Sr. Cloud Consultant* | Cloud Management Practice Google Voice: 423-618-1414 Cell/Text: 423-774-3188 Click here to view my Certification Portfolio <http://red.ht/1XMX2Mi>

3 3

USB on host support?
by Hetz Ben Hamo 29 Jun '19

29 Jun '19

Hi, I'm in communication with a company that thinks about RHV. One of the requirements is USB host support (which will be on the nodes, not on the desktops). I haven't found any way to connect USB to a VM other then through SPICE, but this method won't help as these dongles won't be on desktops. Is this in the road map of oVirt? Thanks

1 0

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

28 Jun '19

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 28-06 for mom due to failed test: 002_bootstrap.add_master_storage_domain. this is a known issue which has a fix which was probably not added to the upgrade suite. I re-triggered the change to see if it passes *CQ-4.3*: GREEN (#2) Last failure was on 27-06-2019 for project ovirt-web-ui due to test get_host_device which seemed to be a race. I re-triggered the patch and it passed. *CQ-Master:* GREEN (#1) Last failure was on 28-06-3019 for project ovirt-node-ng-image on build-artifacts for fc29 There is a ticket opened https://ovirt-jira.atlassian.net/browse/OVIRT-2747 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

[VDSM] New random failure on Fedora 29
by Nir Soffer 26 Jun '19

26 Jun '19

I had this unrelated failure now, never seen it before. ====================================================================== ERROR: test_event_handler (client_test.VdsmClientTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/testValidation.py", line 274, in wrapper return f(*args, **kwargs) File "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/client_test.py", line 220, in test_event_handler client.Test.sendEvent() File "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/lib/vdsm/client.py", line 294, in _call raise TimeoutError(method, kwargs, timeout) TimeoutError: Request Test.sendEvent with args {} timed out after 3 seconds Build: https://jenkins.ovirt.org/job/vdsm_standard-check-patch/6692//artifact/chec… Looking at the captured logs, we see this alarming error: 2019-06-24 19:49:58,108 ERROR (Detector thread) [vds.dispatcher] uncaptured python exception,closing channel <yajsonrpc.betterAsyncore.Dispatcher ('::1', 34444, 0, 0) at 0x7f74983a5c20> (<type 'exceptions.AttributeError'>:'NoneType' object has no attribute 'headers' [/usr/lib64/python2.7/asyncore.py|readwrite|108] [/usr/lib64/python2.7/asyncore.py|handle_read_event|449] [vdsm/lib/yajsonrpc/betterAsyncore.py|handle_read|71] [vdsm/lib/yajsonrpc/betterAsyncore.py|_delegate_call|168] [vdsm/lib/vdsm/protocoldetector.py|handle_read|129] [vdsm/lib/yajsonrpc/stompserver.py|handle_socket|412] [vdsm/lib/vdsm/rpc/bindingjsonrpc.py|add_socket|54] [vdsm/lib/yajsonrpc/stompserver.py|createListener|379] [vdsm/lib/yajsonrpc/stompserver.py|StompListener|345] [vdsm/lib/yajsonrpc/betterAsyncore.py|__init__|47] [vdsm/lib/yajsonrpc/betterAsyncore.py|switch_implementation|86] [vdsm/lib/yajsonrpc/stompserver.py|init|363] [vdsm/lib/vdsm/rpc/bindingjsonrpc.py|_onAccept|57] [vdsm/lib/yajsonrpc/stomp.py|set_message_handler|635] [/usr/lib64/python2.7/asyncore.py|handle_read_event|449] [vdsm/lib/yajsonrpc/betterAsyncore.py|handle_read|71] [vdsm/lib/yajsonrpc/betterAsyncore.py|_delegate_call|168] [vdsm/lib/yajsonrpc/stomp.py|handle_read|411] [vdsm/lib/yajsonrpc/stomp.py|parse|313] [vdsm/lib/yajsonrpc/stomp.py|_parse_header|249]) (betterAsyncore:179) Unhandled exception means we did not implement some handle_error, and we got the default error handling which give very unhelpful tracebacks: https://github.com/python/cpython/blob/6cbff564f00fbe17b5443f6986a44ce116d3… So we have 2 issues: - missing handle_error - fixing this first will help to fix the actual error bellow - the actual error: 'NoneType' object has no attribute 'headers', from: yajsonrpc/stomp.py line 249 Nir

2 2

yum x dnf on el8 host installation?
by Milan Zamazal 26 Jun '19

26 Jun '19

Hi, when I experiment with installing a RHEL 8 host from Engine (master branch running on RHEL 7), I get the following error in host deploy: 2019-06-25 12:59:48,701+0200 DEBUG otopi.plugins.otopi.network.firewalld firewalld._get_firewalld_cmd_version:116 firewalld version: 0.6.3 2019-06-25 12:59:48,701+0200 DEBUG otopi.plugins.otopi.dialog.machine dialog.__logString:204 DIALOG:SEND **%EventEnd STAGE customization METHOD otopi.plugins.otopi.network.firewalld.Plugin._customization (None) 2019-06-25 12:59:48,701+0200 DEBUG otopi.context context.dumpEnvironment:731 ENVIRONMENT DUMP - BEGIN 2019-06-25 12:59:48,702+0200 DEBUG otopi.context context.dumpEnvironment:741 ENV NETWORK/firewalldAvailable=bool:'True' 2019-06-25 12:59:48,702+0200 DEBUG otopi.context context.dumpEnvironment:745 ENVIRONMENT DUMP - END 2019-06-25 12:59:48,702+0200 DEBUG otopi.context context._executeMethod:127 Stage customization METHOD otopi.plugins.otopi.core.config.Plugin._customize1 2019-06-25 12:59:48,702+0200 DEBUG otopi.plugins.otopi.dialog.machine dialog.__logString:204 DIALOG:SEND **%EventStart STAGE customization METHOD otopi.plugins.otopi.core.config.Plugin._customize1 (None) 2019-06-25 12:59:48,703+0200 DEBUG otopi.plugins.otopi.dialog.machine dialog.__logString:204 DIALOG:SEND **%EventEnd STAGE customization METHOD otopi.plugins.otopi.core.config.Plugin._customize1 (None) 2019-06-25 12:59:48,703+0200 DEBUG otopi.context context._executeMethod:127 Stage customization METHOD otopi.plugins.ovirt_host_deploy.kdump.packages.Plugin._customization 2019-06-25 12:59:48,703+0200 DEBUG otopi.plugins.otopi.dialog.machine dialog.__logString:204 DIALOG:SEND **%EventStart STAGE customization METHOD otopi.plugins.ovirt_host_deploy.kdump.packages.Plugin._customization (None) 2019-06-25 12:59:48,704+0200 DEBUG otopi.context context._executeMethod:145 method exception Traceback (most recent call last): File "/tmp/ovirt-AX5hJa1Fcr/pythonlib/otopi/context.py", line 132, in _executeMethod method['method']() File "/tmp/ovirt-AX5hJa1Fcr/otopi-plugins/ovirt-host-deploy/kdump/packages.py", line 216, in _customization self._kexec_tools_version_supported() File "/tmp/ovirt-AX5hJa1Fcr/otopi-plugins/ovirt-host-deploy/kdump/packages.py", line 143, in _kexec_tools_version_supported from rpmUtils.miscutils import compareEVR ModuleNotFoundError: No module named 'rpmUtils' 2019-06-25 12:59:48,705+0200 ERROR otopi.context context._executeMethod:154 Failed to execute stage 'Environment customization': No module named 'rpmUtils' It's apparently because `rpmUtils' module from `yum' package is no longer present on RHEL 8 (in `yum' or another very easily guessable package). I'm not sure how el7 x el8 host installation is supposed to work and whether I can do anything at the moment to proceed a bit further. I suppose similar yum x dnf issues will need some attention; not only in host deploy but everywhere where yum or rpm manipulation is used. Thanks, Milan

3 3

Re: [CentOS-devel] The future of the community build services
by Sandro Bonazzola 26 Jun '19

26 Jun '19

Hi, Il giorno lun 24 giu 2019 alle ore 17:21 Thomas Oulevey < thomas.oulevey(a)cern.ch> ha scritto: > Hi Folks, > > It's time to have a look to the SIGs and the community needs for the > next version of the community build service(cbs). We would like to > request feedback and know if the different communities plan on using > modular builds, and what would be their timeline to be able to produce > C8 artifacts (rpms, imagefactory builds, etc...). > From oVirt perspective we are not planning to build modules but we need to see how advanced virtualization module will look like within CentOS 8. We plan to consume some modules but not building one also for building in cbs (we'll need at least javapackages-tools module in cbs build root) > > As you know Koji is now used to build CentOS 8 [1], and is based on > the mbbox [2] distribution. > > It makes sense for cbs.centos.org to follow this trend and be based on > the same templates. > > At the same time we needed to evaluate how and where we can deploy the > new Openshift based templates, and associated builders for different > arches. > > It's understood that the transition between both systems should be > smooth and do not impact your C6/C7 builds and release cycle. We will > plan accordingly. > > Please let us know, if you have comments and/or new ideas. > > -- > Thomas Oulevey > > > [1]: https://blog.centos.org/2019/06/centos-8-status-17-june-2019/ > [2]: https://github.com/puiterwijk/mbbox > _______________________________________________ > CentOS-devel mailing list > CentOS-devel(a)centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/>

1 0

Fwd: [CentOS-devel] The future of the community build services
by Sandro Bonazzola 25 Jun '19

25 Jun '19

FYI ---------- Forwarded message --------- Da: Thomas Oulevey <thomas.oulevey(a)cern.ch> Date: lun 24 giu 2019 alle ore 17:21 Subject: [CentOS-devel] The future of the community build services To: <centos-devel(a)centos.org> Hi Folks, It's time to have a look to the SIGs and the community needs for the next version of the community build service(cbs). We would like to request feedback and know if the different communities plan on using modular builds, and what would be their timeline to be able to produce C8 artifacts (rpms, imagefactory builds, etc...). As you know Koji is now used to build CentOS 8 [1], and is based on the mbbox [2] distribution. It makes sense for cbs.centos.org to follow this trend and be based on the same templates. At the same time we needed to evaluate how and where we can deploy the new Openshift based templates, and associated builders for different arches. It's understood that the transition between both systems should be smooth and do not impact your C6/C7 builds and release cycle. We will plan accordingly. Please let us know, if you have comments and/or new ideas. -- Thomas Oulevey [1]: https://blog.centos.org/2019/06/centos-8-status-17-june-2019/ [2]: https://github.com/puiterwijk/mbbox _______________________________________________ CentOS-devel mailing list CentOS-devel(a)centos.org https://lists.centos.org/mailman/listinfo/centos-devel -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/>

1 0

vdsm has been tagged (v4.30.22)
by Milan Zamazal 25 Jun '19

25 Jun '19

1 0

Weakness of repos in OST
by Dominik Holler 25 Jun '19

25 Jun '19

Hi, from my point of view, we are not testing the repos in OST, because we manage the packages manually. The clean way would be installing something like https://resources.ovirt.org/pub/yum-repo/ovirt-release43-pre.rpm But this would download each package multiple times each run. Maybe a way to test the repos would be an OST which bypasses lago's repo management. What is your view on this? Dominik

2 1

ovirt-engine has been tagged (ovirt-engine-4.3.5.2)
by Tal Nisan 25 Jun '19

25 Jun '19

1 0

vdsm has been tagged (v4.30.21)
by Milan Zamazal 25 Jun '19

25 Jun '19

1 0

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

24 Jun '19

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 18-06 for project v2v-conversion-host due to failed build-artifacts which is already fixed by next merged patches. *CQ-4.3*: RED (#1) 1. We have a failure on ovirt-engine-metrics due to a dependency to a new ansible package that has not been synced yet to centos repo. I am adding virt-sig-common repo until this is synced next week: https://gerrit.ovirt.org/#/c/101023/ *CQ-Master:* RED (#1) 1. same failure on ovirt-engine-metrics as 4.3 2. ovirt-hosted-engine-setup is failing due to package dependency change from python-libguestfs to python2-libguestfs. mail sent to Ido to check the issue. 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)

2 2

Builds on s390x fail again
by Nir Soffer 21 Jun '19

21 Jun '19

I cannot see any reason for the failure in the pipeline logs, and there are no build logs. https://jenkins.ovirt.org/job/standard-manual-runner/329/ https://jenkins.ovirt.org/job/standard-manual-runner/329//artifact/build-ar… The el7 x86_64 repo was created, so I can still use this build to run OST, but we need to fix this quickly, or disable the s390x builds until we have a stable solution. Nir

2 1

review request: SDM update_volume API changes
by Germano Veit Michel 21 Jun '19

21 Jun '19

Hello, Could you please review and comment on the following patch series below? https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:s… These are required by future tools to make fixing image chains safer and easier. This has been previously submitted as part of a larger set of patches, which were not accepted mostly due to a ResourceManager Exception workaround (force flag). The series above removes that workaround and also improves the tests. I'm only submitting the API changes at this time. If you want to have an idea on what this will be used for, please see now abandoned https://gerrit.ovirt.org/#/c/94105/ (it will get updated and resubmitted once and if these API changes are accepted) Thanks, Germano

1 1

Most el7 vdsm build fail to fetch source - bad slave?
by Nir Soffer 21 Jun '19

21 Jun '19

I have see many such failures today, here is 2 bulids - both on same slave (slave issue?) 1. [2019-06-20T22:23:12.401Z] Running on node: vm0015.workers-phx.ovirt.org (el7 phx nested local_disk) https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa… 2. [2019-06-20T22:20:50.288Z] Running on node: vm0015.workers-phx.ovirt.org (el7 phx nested local_disk) https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa… Looks like there was no build on this slave in the last 2 days: https://jenkins.ovirt.org/computer/vm0015.workers-phx.ovirt.org/builds The failure looks like this: [2019-06-20T22:23:16.416Z] No credentials specified [2019-06-20T22:23:16.440Z] Fetching changes from the remote Git repository [2019-06-20T22:23:16.456Z] Cleaning workspace [2019-06-20T22:23:16.566Z] ERROR: Error fetching remote repo 'origin' [2019-06-20T22:23:16.566Z] hudson.plugins.git.GitException: Failed to fetch from https://gerrit.ovirt.org/vdsm [2019-06-20T22:23:16.566Z] at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:894) [2019-06-20T22:23:16.566Z] at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161) [2019-06-20T22:23:16.566Z] at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192) [2019-06-20T22:23:16.566Z] at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:120) [2019-06-20T22:23:16.566Z] at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:90) [2019-06-20T22:23:16.566Z] at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:77) [2019-06-20T22:23:16.566Z] at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47) [2019-06-20T22:23:16.566Z] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [2019-06-20T22:23:16.566Z] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [2019-06-20T22:23:16.566Z] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [2019-06-20T22:23:16.566Z] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [2019-06-20T22:23:16.566Z] at java.lang.Thread.run(Thread.java:748) [2019-06-20T22:23:16.566Z] Caused by: hudson.plugins.git.GitException: Command "git clean -fdx" returned status code 1: [2019-06-20T22:23:16.566Z] stdout: [2019-06-20T22:23:16.566Z] stderr: warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage___init___py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_asyncevent_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_asyncutils_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_blkdiscard_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_blockSD_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_blockVolume_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_blockdev_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_check_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_clusterlock_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_compat_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_constants_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_curlImgWrap_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_devicemapper_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_directio_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_dispatcher_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_exception_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_fallocate_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_fileSD_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_fileUtils_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_fileVolume_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_formatconverter_py.html [2019-06-20T22:23:16.566Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_fsutils_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_fuser_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_glusterSD_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_glusterVolume_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_guarded_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_hba_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_hsm_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_image_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_imageSharing_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_imagetickets_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_iscsi_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_iscsiadm_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_localFsSD_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_lvm_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_lvmconf_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_lvmfilter_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_mailbox_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_managedvolume_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/index.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_managedvolumedb_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_merge_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_misc_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_monitor_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_mount_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_mpathhealth_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_multipath_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_nbd_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_nfsSD_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_nos_brick_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_operation_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_outOfProcess_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_persistent_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_qemuimg_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_resourceFactories_py.html [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/status.json [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/style.css [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/jquery.min.js [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/jquery.ba-throttle-debounce.min.js [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/jquery.hotkeys.js [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/jquery.isonscreen.js [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/jquery.tablesorter.min.js [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/coverage_html.js [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/keybd_closed.png [2019-06-20T22:23:16.567Z] warning: failed to remove tests/htmlcov-storage-py27/keybd_open.png [2019-06-20T22:23:16.567Z] [2019-06-20T22:23:16.567Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2042) [2019-06-20T22:23:16.567Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2010) [2019-06-20T22:23:16.567Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2006) [2019-06-20T22:23:16.567Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1638) [2019-06-20T22:23:16.567Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1650) [2019-06-20T22:23:16.567Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.clean(CliGitAPIImpl.java:828) [2019-06-20T22:23:16.567Z] at hudson.plugins.git.GitAPI.clean(GitAPI.java:311) [2019-06-20T22:23:16.567Z] at sun.reflect.GeneratedMethodAccessor88.invoke(Unknown Source) [2019-06-20T22:23:16.567Z] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [2019-06-20T22:23:16.567Z] at java.lang.reflect.Method.invoke(Method.java:498) [2019-06-20T22:23:16.567Z] at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:929) [2019-06-20T22:23:16.567Z] at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:903) [2019-06-20T22:23:16.567Z] at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:855) [2019-06-20T22:23:16.567Z] at hudson.remoting.UserRequest.perform(UserRequest.java:212) [2019-06-20T22:23:16.567Z] at hudson.remoting.UserRequest.perform(UserRequest.java:54) [2019-06-20T22:23:16.567Z] at hudson.remoting.Request$2.run(Request.java:369) [2019-06-20T22:23:16.567Z] at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) [2019-06-20T22:23:16.567Z] ... 4 more [2019-06-20T22:23:16.568Z] Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to vm0015.workers-phx.ovirt.org [2019-06-20T22:23:16.568Z] at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743) [2019-06-20T22:23:16.568Z] at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) [2019-06-20T22:23:16.568Z] at hudson.remoting.Channel.call(Channel.java:957) [2019-06-20T22:23:16.568Z] at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:283) [2019-06-20T22:23:16.568Z] at com.sun.proxy.$Proxy83.clean(Unknown Source) [2019-06-20T22:23:16.568Z] at org.jenkinsci.plugins.gitclient.RemoteGitImpl.clean(RemoteGitImpl.java:450) [2019-06-20T22:23:16.568Z] at hudson.plugins.git.extensions.impl.CleanBeforeCheckout.decorateFetchCommand(CleanBeforeCheckout.java:30) [2019-06-20T22:23:16.568Z] at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:890) [2019-06-20T22:23:16.568Z] at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161) [2019-06-20T22:23:16.568Z] at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192) [2019-06-20T22:23:16.568Z] at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:120) [2019-06-20T22:23:16.569Z] at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:90) [2019-06-20T22:23:16.569Z] at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:77) [2019-06-20T22:23:16.569Z] at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47) [2019-06-20T22:23:16.569Z] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [2019-06-20T22:23:16.569Z] ... 4 more [2019-06-20T22:23:16.421Z] > git rev-parse --is-inside-work-tree # timeout=10 [2019-06-20T22:23:16.444Z] > git config remote.origin.url https://gerrit.ovirt.org/vdsm # timeout=10 [2019-06-20T22:23:16.459Z] > git rev-parse --verify HEAD # timeout=10 [2019-06-20T22:23:16.466Z] Resetting working tree [2019-06-20T22:23:16.466Z] > git reset --hard # timeout=10 [2019-06-20T22:23:16.514Z] > git clean -fdx # timeout=10 Error fetching remote repo 'origin'

1 1

export domain bug?
by Hetz Ben Hamo 20 Jun '19

20 Jun '19

Hi, Clicking on compute, templates, the HE complains that the export domain is not available. Isn't export domain deprecated and the import window should default to the a storage domain? Should I open a bug in Bugzilla? Thanks Hetz

1 0

Re: [Bug 1721581] Ansible 2.8 needed for ovirt-metrics
by Charles Thao 20 Jun '19

20 Jun '19

On Thu, Jun 20, 2019 at 6:53 AM <bugzilla(a)redhat.com> wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1721581 > > Shirly Radco <sradco(a)redhat.com> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Status|POST |MODIFIED > Flags|needinfo?(sradco(a)redhat.com | > |) | > > > > -- > You are receiving this mail because: > You reported the bug.

1 0

Test failure on Fedora 29
by Nir Soffer 19 Jun '19

19 Jun '19

We have new random failure in this test: [2019-06-18T16:05:56.576Z] =================================== FAILURES =================================== [2019-06-18T16:05:56.576Z] _________________ SSLTests.testConnectWithoutCertificateFails __________________ [2019-06-18T16:05:56.576Z] [2019-06-18T16:05:56.576Z] self = <ssl_test.SSLTests testMethod=testConnectWithoutCertificateFails> [2019-06-18T16:05:56.576Z] [2019-06-18T16:05:56.576Z] def testConnectWithoutCertificateFails(self): [2019-06-18T16:05:56.576Z] """ [2019-06-18T16:05:56.576Z] Verify that the connection without a client certificate [2019-06-18T16:05:56.576Z] fails. [2019-06-18T16:05:56.576Z] """ [2019-06-18T16:05:56.576Z] [2019-06-18T16:05:56.576Z] with self.assertRaises(cmdutils.Error): [2019-06-18T16:05:56.576Z] args = ["openssl", "s_client", "-connect", "%s:%d" % self.address] [2019-06-18T16:05:56.576Z] > commands.run(args) [2019-06-18T16:05:56.576Z] E AssertionError: Error not raised [2019-06-18T16:05:56.576Z] [2019-06-18T16:05:56.576Z] ssl_test.py:173: AssertionError The build: https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa… https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/vdsm_st… Marcin, can you look at it?

2 3

vdsm has been tagged (v4.30.20)
by Milan Zamazal 18 Jun '19

18 Jun '19

1 0

ovirt-engine has been tagged (ovirt-engine-4.3.5.1)
by Tal Nisan 18 Jun '19

18 Jun '19

1 0

Low Performance Issue
by Akshita Jain 17 Jun '19

17 Jun '19

I've setup oVirt HCI over 3 servers. Each server has 1* 480 GB SSD, 5* 1.8 TB SAS HDD with oVirt version 4.3.3 But I am still able to get low performance. Can anyone suggest the tuning variables for Gluster volume. Remark :What should the value be set for network.remote-dio= enable / disable ?

2 2

[storage] isolating images
by Germano Veit Michel 17 Jun '19

17 Jun '19

Hello, When there are image chains problems, sometimes it is not possible to determine the correct chain due to lost information like rotated logs. For this cases, it is usually desirable to remove a volume from the chain but not from the storage until the user confirms the VM is healthy and contains the correct data. Currently this is done by moving files (file storage) or renaming LVM tags (block storage) so VDSM does not find the particular volume to be part of the chain. Ideally I would like to have this done by a vdsm-tool talking to VDSM api. The tool would be able to mark the volume to be ignored or not, list all ignored volumes and perhaps even delete them (to free space). How would you recommend proceeding with such tool? Some ideas: - Have a reserved image UUID which contains all ignored volumes, so they are not part of any chain. - Add an "ignore" metadata attribute to each volume. I like more the first option, but looking for opinions and ideas. Thanks, Germano

1 0

ovirt-system-tests_hc-basic-suite-master failing
by Gobinda Das 14 Jun '19

14 Jun '19

Hi, hc-basic-suite-master build is failing due to sanlock-python dependency issue. Error: Package: vdsm-4.40.0-338.gitaaf7f44.el7.x86_64 (alocalsync) Requires: sanlock-python >= 3.7.3 Installing: sanlock-python-3.6.0-1.el7.x86_64 (alocalsync) sanlock-python = 3.6.0-1.el7 Can anyone please help? -- Thanks, Gobinda

2 1

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

14 Jun '19

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 (#3) 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 *CQ-4.3*: GREEN (#1) There were two main failures this week. 1. vdsm was failing due to the sos change which was causing metrics tests to fail as it was using vdsm sos plugin and that is no longer available. this was fix by mperina: https://gerrit.ovirt.org/100716 https://gerrit.ovirt.org/100809 2. there was a general failure due to packages. two patches were merged to fix the issue: https://gerrit.ovirt.org/#/c/100764/ https://gerrit.ovirt.org/#/c/100691/ *CQ-Master:* GREEN (#1) Master was failing on the same issues as in 4.3 which are now 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

adding host to oVirt issue
by Hetz Ben Hamo 14 Jun '19

14 Jun '19

Hi, I have been checking oVirt latest (4.3.4) with adding various bare metal hosts with various CPU's: I'm asking on this mailing list if I should open a ticket and if so what ticket (bug? RFE?). - AMD Ryzen 5 - Xeon SP (first gen) - Xeon SP (second gen) - Upcoming unannounced Xeon CPU. The main oVirt machine (and the HE) is running on Xeon E3-1225 V3 CPU. The big problem is that when you add for example any AMD processor (whatever it's a low end Ryzen 5 or a high end 32 cores EPYC) to such a setup, it will fail because it tries to add the AMD machine to the default cluster which is defined as Intel based VT-X. If I'll try to add any non Xeon V3 CPU, it will succeed, but any live migration of VM's inside the cluster will fail since any Xeon chip version has various VT flags. So, my suggestion is that when adding nodes/hosts to oVirt, they will be added to a new "non clustered" place without any features allowed (live migration, for example) and after the admin will add the machines, he/she can assign nodes to a defined cluster (prepared or that he/she can create) Another problem with cluster defining is that the CPU type is too complicated for any admin who doesn't know the nuts and bolts of each CPU. For example - the Haswell CPU type got *6* CPU types. Do you really expect an admin to know which one to select? IMHO, a good solution would be to add some "detect" button to hosts, and the result from clicking this button should be a window with options like: - Add this host to an existing cluster (which has the same CPU type) - Auto create a new cluster with the CPU type detected from the node/host CPU I'll be happy to hear your thoughts about this issue. Thanks, Hetz

1 0

[ OST Failure Report ] [ oVirt Master (vdsm) ] [ 07-06-2019 ] [ 003_00_metrics_bootstrap.metrics_and_log_collector ]
by Dafna Ron 14 Jun '19

14 Jun '19

Hi, We have a failure in vdsm project on master. The issue is change: https://gerrit.ovirt.org/#/c/100576/ - Remove SOS VDSM plugin which is failing on metrics as metrics is calling sos-logcollector. The patch cannot be changed as until centos 7.7 when sos-3.7-3, which contains vdsm plugin will come out. so until then, we are left with no sos plugin, which is causing the metrics test to fail. Shirly, can you please take a look and see if we can change the test to not call sos-logcollector? Please note, that we are expecting 4.3 to fail on same issue very soon. failed job can be found here: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14452/ ERROR from test: lago.ssh: DEBUG: Command 8626fe70 on lago-basic-suite-master-engine errors: ERROR: Failed to get a sosreport from: lago-basic-suite-master-host-1; Could not parse sosreport output ERROR: Failed to get a sosreport from: lago-basic-suite-master-host-0; Could not parse sosreport output lago.utils: DEBUG: Error while running thread Thread-3 Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in _ret_via_queue queue.put({'return': func()}) File "/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/003_00_metrics_bootstrap.py", line 97, in run_log_collector 'log collector failed. Exit code is %s' % result.code File "/usr/lib64/python2.7/unittest/case.py", line 462, in assertTrue raise self.failureException(msg) AssertionError: log collector failed. Exit code is 1 --------------------- >> end captured logging << ---------- Thanks, Dafna

7 21

Host installation error
by Charles Thao 13 Jun '19

13 Jun '19

Hi, I have a 4.3 engine on Fedora 28 laptop and a 4.3 node running on a virt-manager. I installed ovirt-node using the latest stable ISO image. When I tried to connect the host to my engine, this error appeared: *Host node installation failed. Failed to execute Ansible host-deploy role.* I've also attached an example log file. Has anyone seen anything similar to this? Regards, Charles T

1 0

Dropping Fedora 28 support in oVirt development repos and jenkins
by Sandro Bonazzola 13 Jun '19

13 Jun '19

Hi, while we are introducing support for fedora 29 and 30 we need to free resources both on jenkins and on resources.ovirt.org. Starting today I'll start pushing removal of fc28 jenkins jobs. Once done, I'm going to remove the fc28 repositories from all snapshot and tested repos, keeping fc28 repos only within the released repositories. Thanks, -- 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 9

Sanlock 3.8.0-1 for Fedora 30 is available for testing
by Nir Soffer 12 Jun '19

12 Jun '19

Whats new in 3.8.0? - Supports python 2.7, 3.6, 3.7, 3.8 - Built for python 3 only You can grab it here now: https://koji.fedoraproject.org/koji/buildinfo?buildID=1286742 It should be available tomorrow in updates-testing repo. Please test and leave feedback here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-7612da9fe7 Nir

1 0

Issues when running VDSM tests
by Pavel Bar 12 Jun '19

12 Jun '19

Hi Milan, Can you please check the following VDSM tests's failures: *Environment:* 1) VDSM master branch; 2) Fedora 29 OS *Execution (from root folder):* *make check* *Issues:* 1) An authentication pop-up window jumps when executing: *Warning no default label for /tmp/tmpRCRsYm/libvirtd.............................................................SS.........................................S.SS..S................S.S..................................................................SSS..SSSSS..SSSSSSS.................SSS..SSS...S..............SSSS..SS.....S.........SSSSS.S.S.........................SSSSS....SSSSSS......................................S..SSSSSSSSS.SS.........................................................................................................................................................................----------------------------------------------------------------------* 2) 2 error outputs received, the 2nd one multiple times: *ERROR: InvocationError for command '/home/pbar/Dev/git/vdsm/pbar/master/tests/profile network-py27 ./py-watch 600 pytest --durations=5 --cov=vdsm.network --cov-report=html:htmlcov-network-py27 --cov-fail-under=42 network/integration network/unit' (exited with code 1)* *E HookError: Hook Error: ('Traceback (most recent call last):\n File "/usr/libexec/vdsm/hooks/before_nic_hotplug/50_vmfex", line 35, in <module>\n from vdsm import libvirtconnection\nImportError: cannot import name libvirtconnection\n',)../lib/vdsm/common/hooks.py:124: HookError* Thank you in advance! Pavel

2 1

Building python 2 and python 3 packages for Fedora
by Nir Soffer 12 Jun '19

12 Jun '19

In several projects (e.g. vdsm, imageio, sanlock), we have the issue of building python 3 packages for Fedora. The current build process create packages with the same name for both python 2 and python 3. When the packages are published to oVirt repository, the python 3 packages overwrite the python 2 packages. We can rename the packages properly (e.g. python2-xxx, python3-xxx) but this requires lot of work and typically breaks later in the code publishing the packages. There is also the difficulty of building both python 2 and python 3 packages from same spec in the same build. This should be possible but not easy. Since python 2 is about to die soon, should we simplify by building python 2 *or* python 3, depending on version? Fedora 29: python 2.7 Fedora 30: python 3.7 CentOS 7: python 2.7 CentOS 8: python 3.6 This make it possible to test and develop on python 2.7 until vdsm is fully functional on python 3, and it save resources in the CI. Thoughts? Nir

3 4

Failed to add fedora-29 host to oVirt
by Eyal Shenitzky 12 Jun '19

12 Jun '19

Hi, I am trying to add fedora-29 host to me oVirt setup and failed due to the following error (from the engine log): 2019-06-11 11:24:59,123+03 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) [73c7d83d] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An error has occurred during installation of Host fedora_29: DNF Problem: conflicting requests - package ovirt-host-4.4.0-0.0.master.20190610132028.git410e453.fc29.x86_64 requires ovirt-hosted-engine-setup, but none of the providers can be installed - package ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x does not have a compatible architecture - nothing provides ovirt-host-dependencies = 4.4.0-0.0.master.20190610131544.git410e453.fc29 needed by ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch - nothing provides vdsm-python >= 4.30 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch - nothing provides glusterfs-cli >= 5.6 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch - nothing provides vdsm-python >= 4.40.0 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch. 2019-06-11 11:24:59,133+03 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) [73c7d83d] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An error has occurred during installation of Host fedora_29: Failed to execute stage 'Package installation': Problem: conflicting requests - package ovirt-host-4.4.0-0.0.master.20190610132028.git410e453.fc29.x86_64 requires ovirt-hosted-engine-setup, but none of the providers can be installed - package ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x does not have a compatible architecture - nothing provides ovirt-host-dependencies = 4.4.0-0.0.master.20190610131544.git410e453.fc29 needed by ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch - nothing provides vdsm-python >= 4.30 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch - nothing provides glusterfs-cli >= 5.6 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch - nothing provides vdsm-python >= 4.40.0 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch. When I try to install VDSM manually before adding the host the setup it installed the following version: vdsm-4.18.999-447.git0bb7717.fc28.x86_64 Any suggestions? -- Regards, Eyal Shenitzky

2 3

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

ovirt-engine has been tagged (ovirt-engine-4.3.4.3)
by Tal Nisan 05 Jun '19

05 Jun '19

1 0

Planned restart of production services
by Evgheni Dereveanchin 05 Jun '19

05 Jun '19

Hi everyone, I will be restarting several production systems within the following hour to apply updates. The following services may be unreachable for some period of time: - resources.ovirt.org - package repositories - jenkins.ovirt.org - CI master - glance.ovirt.org - Glance image repository Package repositories will be unreachable for a short period of time. No new CI jobs will be started during this period. I will announce you once maintenance is complete. -- Regards, Evgheni Dereveanchin

1 1

Feature Request: oVirt to warn when VDO is getting full
by Strahil 04 Jun '19

04 Jun '19

Hello All, I would like to ask how many of you use VDO before asking the oVirt Devs to assess a feature in oVirt for monitoring the size of the VDOs on hyperconverged systems. I think such warning, will save a lot of headaches, but it will not be usefull if most of the community is not using VDO at all. Best Regards, Strahil Nikolov

3 2