December 2018 - 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 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

propose Ravi Nori as a frontend maintainer for ovirt-engine infra
by Greg Sheremeta 05 Feb '19

05 Feb '19

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 5

query on running OST
by Pooja Pandey 23 Jan '19

23 Jan '19

Hello Team, Could you please help me in answering a query about OST run.I am trying to run on a virtual machine and it is failing with an error that libvirtError: unsupported configuration: Domain requires KVM, but it is not available. Is it necessary to run this Ovirt System Test on a hypervisor only?Please reply on this so that I can proceed further.Thanks.... Regards, Pooja -- DISCLAIMER - *MSysTechnologies LLC* This email message, contents and its attachments may contain confidential, proprietary or legally privileged information and is intended solely for the use of the individual or entity to whom it is actually intended. If you have erroneously received this message, please permanently delete it immediately and notify the sender. If you are not the intended recipient of the email message,you are notified strictly not to disseminate,distribute or copy this e-mail.E-mail transmission cannot be guaranteed to be secure or error-free as Information could be intercepted, corrupted, lost, destroyed, incomplete or contain viruses and MSysTechnologies LLC accepts no liability for the contents and integrity of this mail or for any damage caused by the limitations of the e-mail transmission.

5 9

SSO with lightdm
by jeremiah52＠naver.com 15 Jan '19

15 Jan '19

I knows there are the GDM plugin and KDM plugin of ovirt-guest-agent that makes SSO in linux is possible. I want to make SSO with lightdm is possble. To add lightdm plugin to ovirt-guest-agent is enough? or something more is needed? I don't know how to develop SSO with lightdm.

3 2

Can we drop fc27 jobs / rpms from CI/tested repos?
by Eyal Edri 13 Jan '19

13 Jan '19

5 8

Please review "dump-chains-sqlite"
by Germano Veit Michel 07 Jan '19

07 Jan '19

Hi, With these 2 changes the ovirt-log-collector will collect storage domain metadata from all storage domains of the environment in a more efficient way. https://gerrit.ovirt.org/#/q/topic:dump-chains-sqlite I'll be away for the next 2 weeks, but reviews are welcome. If there is any problem with one of these patches, please don't merge any of them as they require each other. And if you have extra time, reviews are welcome on this series too =D https://gerrit.ovirt.org/#/q/topic:snapshot-tools Thanks, Germano

2 2

Failed to add host to oVirt
by Eyal Shenitzky 02 Jan '19

02 Jan '19

Hey, I am failing to add a host to oVirt due to the following error: 2018-12-23 11:15:29,482+0200 ERROR otopi.context context._executeMethod:152 Failed to execute stage 'Environment customization': Cannot find a valid baseurl for repo: ovirt -master-centos-gluster5/7Server/x86_64 Does someone encounter this issue? -- Regards, Eyal Shenitzky

2 1

ovirt-node-ng-image_4.3_build-artifacts-fc28-x86_64 #39 stuck for 2 days
by Nir Soffer 31 Dec '18

31 Dec '18

Started 2 days 11 hr ago Build has been executing for 2 days 11 hr on vm0038.workers-phx.ovirt.or <https://jenkins.ovirt.org/computer/vm0038.workers-phx.ovirt.org> https://jenkins.ovirt.org/job/ovirt-node-ng-image_4.3_build-artifacts-fc28-…

4 3

[VDSM] Tests fail because of network timeout
by Nir Soffer 26 Dec '18

26 Dec '18

First time I see this error. The issue seems to be network read timeout when creating virtual env in tox test. If you see this error in your builds, please report. storage-py27 create: /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/.tox/storage-py27 ERROR: invocation failed (exit code 1), logfile: /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/.tox/storage-py27/log/storage-py27-0.log ERROR: actionid: storage-py27 msg: getenv cmdargs: ['/usr/bin/python2', '-m', 'virtualenv', '--system-site-packages', '--python', '/usr/bin/python2.7', 'storage-py27'] New python executable in /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/.tox/storage-py27/bin/python2.7 Also creating executable in /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/.tox/storage-py27/bin/python Installing setuptools, pip, wheel... Complete output from command /home/jenkins/worksp...e-py27/bin/python2.7 - setuptools pip wheel: The directory '/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/.cache/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag. The directory '/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/.cache/pip' or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag. Looking in links: /usr/lib/python2.7/site-packages, /usr/lib/python2.7/site-packages/virtualenv_support Collecting setuptools Downloading https://files.pythonhosted.org/packages/37/06/754589caf971b0d2d48f151c2586f… (573kB) Exception: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-18.1-py2.py3-none-any.whl/pip/_internal/cli/base_command.py", line 143, in main status = self.run(options, args) File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-18.1-py2.py3-none-any.whl/pip/_internal/commands/install.py", line 318, in run resolver.resolve(requirement_set) File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-18.1-py2.py3-none-any.whl/pip/_internal/resolve.py", line 102, in resolve self._resolve_one(requirement_set, req) File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-18.1-py2.py3-none-any.whl/pip/_internal/resolve.py", line 256, in _resolve_one abstract_dist = self._get_abstract_dist_for(req_to_install) File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-18.1-py2.py3-none-any.whl/pip/_internal/resolve.py", line 209, in _get_abstract_dist_for self.require_hashes File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-18.1-py2.py3-none-any.whl/pip/_internal/operations/prepare.py", line 283, in prepare_linked_requirement progress_bar=self.progress_bar File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-18.1-py2.py3-none-any.whl/pip/_internal/download.py", line 836, in unpack_url progress_bar=progress_bar File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-18.1-py2.py3-none-any.whl/pip/_internal/download.py", line 673, in unpack_http_url progress_bar) File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-18.1-py2.py3-none-any.whl/pip/_internal/download.py", line 897, in _download_http_url _download_url(resp, link, content_file, hashes, progress_bar) File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-18.1-py2.py3-none-any.whl/pip/_internal/download.py", line 617, in _download_url hashes.check_against_chunks(downloaded_chunks) File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-18.1-py2.py3-none-any.whl/pip/_internal/utils/hashes.py", line 48, in check_against_chunks for chunk in chunks: File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-18.1-py2.py3-none-any.whl/pip/_internal/download.py", line 585, in written_chunks for chunk in chunks: File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-18.1-py2.py3-none-any.whl/pip/_internal/utils/ui.py", line 159, in iter for x in it: File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-18.1-py2.py3-none-any.whl/pip/_internal/download.py", line 574, in resp_read decode_content=False): File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-18.1-py2.py3-none-any.whl/pip/_vendor/urllib3/response.py", line 465, in stream data = self.read(amt=amt, decode_content=decode_content) File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-18.1-py2.py3-none-any.whl/pip/_vendor/urllib3/response.py", line 430, in read raise IncompleteRead(self._fp_bytes_read, self.length_remaining) File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-18.1-py2.py3-none-any.whl/pip/_vendor/urllib3/response.py", line 345, in _error_catcher raise ReadTimeoutError(self._pool, None, 'Read timed out.') ReadTimeoutError: HTTPSConnectionPool(host='files.pythonhosted.org', port=443): Read timed out. ---------------------------------------- ...Installing setuptools, pip, wheel...done. Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/virtualenv.py", line 2462, in <module> main() File "/usr/lib/python2.7/site-packages/virtualenv.py", line 762, in main symlink=options.symlink, File "/usr/lib/python2.7/site-packages/virtualenv.py", line 1015, in create_environment install_wheel(to_install, py_executable, search_dirs, download=download) File "/usr/lib/python2.7/site-packages/virtualenv.py", line 968, in install_wheel call_subprocess(cmd, show_stdout=False, extra_env=env, stdin=SCRIPT) File "/usr/lib/python2.7/site-packages/virtualenv.py", line 854, in call_subprocess raise OSError("Command {} failed with error code {}".format(cmd_desc, proc.returncode)) OSError: Command /home/jenkins/worksp...e-py27/bin/python2.7 - setuptools pip wheel failed with error code 2 Running virtualenv with interpreter /usr/bin/python2.7 ERROR: Error creating virtualenv. Note that some special characters (e.g. ':' and unicode symbols) in paths are not supported by virtualenv. Error details: InvocationError('/usr/bin/python2 -m virtualenv --system-site-packages --python /usr/bin/python2.7 storage-py27 (see /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/.tox/storage-py27/log/storage-py27-0.log)', 1) Build: https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/vdsm_st…

1 0

Tests failed because global_setup.sh failed
by Nir Soffer 26 Dec '18

26 Dec '18

Not sure why global setup failed: + [[ ! -O /home/jenkins/.ssh ]] + [[ ! -G /home/jenkins/.ssh ]] + verify_set_permissions 700 /home/jenkins/.ssh + local target_permissions=700 + local path_to_set=/home/jenkins/.ssh ++ stat -c %a /home/jenkins/.ssh + local access=700 + [[ 700 != \7\0\0 ]] + return 0 + [[ -f /home/jenkins/.ssh/known_hosts ]] + verify_set_ownership /home/jenkins/.ssh/known_hosts + local path_to_set=/home/jenkins/.ssh/known_hosts ++ id -un + local owner=jenkins ++ id -gn + local group=jenkins + [[ ! -O /home/jenkins/.ssh/known_hosts ]] + [[ ! -G /home/jenkins/.ssh/known_hosts ]] + verify_set_permissions 644 /home/jenkins/.ssh/known_hosts + local target_permissions=644 + local path_to_set=/home/jenkins/.ssh/known_hosts ++ stat -c %a /home/jenkins/.ssh/known_hosts + local access=644 + [[ 644 != \6\4\4 ]] + return 0 + return 0 + true + log ERROR Aborting. Build: https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/vdsm_st…

4 4

Proposing Nir as ovirt-site storage mainainer
by Nir Soffer 25 Dec '18

25 Dec '18

Nir has done significant work on vdsm and ovirt-imageio, and working recently on incremental backup feature page: https://ovirt.org/develop/release-management/features/storage/incremental-b… For some reason he does not have merge right in ovirt-site project. I think it is time to fix this issue. If we can trust his code we can trust his documentation. Thoughts? Nir

9 12

Re: [VDSM] Tests fail with "missing workspace /home/jenkins/workspace/vdsm_standard-check-patch/vdsm on vm0038.workers-phx.ovirt.org"
by Nir Soffer 22 Dec '18

22 Dec '18

On Fri, Dec 21, 2018 at 1:47 AM Nir Soffer <nsoffer(a)redhat.com> wrote: > Third time today: > > Error: > sh: /home/jenkins/workspace/vdsm_standard-check-patch/vdsm@tmp > /durable-15072b7e/jenkins-result.txt.tmp: > No such file or directory > mv: cannot stat > '/home/jenkins/workspace/vdsm_standard-check-patch/vdsm@tmp > /durable-15072b7e/jenkins-result.txt.tmp': > No such file or directory > missing workspace > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm on > vm0013.workers-phx.ovirt.org > > Build: > > https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/vdsm_st… Adding devel - if you see this error please report here. On Thu, Dec 20, 2018 at 10:01 PM Nir Soffer <nsoffer(a)redhat.com> wrote: > > > > Two incidents on a different slaves today: > > > > Error: > > sh: /home/jenkins/workspace/vdsm_standard-check-patch/vdsm@tmp > /durable-d993b7a2/jenkins-result.txt.tmp: > > No such file or directory > > mv: cannot stat > > '/home/jenkins/workspace/vdsm_standard-check-patch/vdsm@tmp > /durable-d993b7a2/jenkins-result.txt.tmp': > > No such file or directory > > missing workspace > > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm on > > vm0088.workers-phx.ovirt.org > > > > Build: > > > https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/vdsm_st… > > > > > > Error: > > sh: /home/jenkins/workspace/vdsm_standard-check-patch/vdsm@tmp > /durable-edec94a0/jenkins-result.txt.tmp: > > No such file or directory > > mv: cannot stat > > '/home/jenkins/workspace/vdsm_standard-check-patch/vdsm@tmp > /durable-edec94a0/jenkins-result.txt.tmp': > > No such file or directory > > missing workspace > > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm on > > vm0013.workers-phx.ovirt.org > > > > Build: > > > https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/vdsm_st… > > > > On Wed, Dec 19, 2018 at 4:36 PM Nir Soffer <nsoffer(a)redhat.com> wrote: > > > > > > I have seen this before, very strange failure. > > > > > > The job run normally and then abort when we start to run the tests. > The error > > > does not come from our tests. > > > > > > Error: > > > ../tests/run_tests_local.sh API_test.py alignmentscan_test.py > > > api_response_test.py bridge_test.py caps_test.py client_test.py > > > clientif_test.py cmdutils_test.py config_test.py cpu_profile_test.py > > > cpuinfo_test.py domcaps_test.py encoding_test.py exception_test.py > > > executor_test.py eventfd_test.py fallocate_test.py filecontrol_test.py > > > fuser_test.py glob_test.py gluster_cli_test.py > > > gluster_exception_test.py glusterTestData.py > > > gluster_thinstorage_test.py hooks_test.py hostdev_test.py > > > hoststats_test.py hugepages_test.py hwinfo_test.py jobs_test.py > > > jsonRpcClient_test.py jsonrpc_test.py loopback_test.py mkimage_test.py > > > modprobe.py moduleloader_test.py monkeypatch_test.py mom_test.py > > > mompolicy_test.py osinfo_test.py osutils_test.py passwords_test.py > > > permutation_test.py protocoldetector_test.py response_test.py > > > rngsources_test.py schedule_test.py schemavalidation_test.py > > > sigutils_test.py sparsify_test.py stompadapter_test.py > > > stompasyncclient_test.py stompasyncdispatcher_test.py stomp_test.py > > > sysprep_test.py taskset_test.py testlib_test.py tool_confmeta_test.py > > > tool_test.py throttledlog_test.py unicode_test.py utils_test.py > > > validate_test.py vdsmapi_test.py vdsmdumpchains_test.py verify.py > > > vmapi_test.py vmfakelib_test.py vmTestsData.py zombiereaper_test.py > > > network/*_test.py devices/parsing/complex_vm_test.py > > > common/cache_test.py common/cmdutils_test.py common/concurrent_test.py > > > common/contextlib_test.py common/fileutils_test.py > > > common/function_test.py common/hostutils_test.py > > > common/libvirtconnection_test.py common/logutils_test.py > > > common/network_test.py common/osutils_test.py common/proc_test.py > > > common/properties_test.py common/pthread_test.py common/time_test.py > > > common/validate_test.py > > > > > > missing workspace > > > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm on > > > vm0038.workers-phx.ovirt.org > > > > > > > > > Build: > > > > https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/vdsm_st… >

1 2

[VDSM] all test passed, build failed with "tar: journal/b087148aba6d49b9bbef488e52a48752/system.journal: file changed as we read it"
by Nir Soffer 21 Dec '18

21 Dec '18

We have this failure that pops randomly: 1. All tests pass *00:13:13.284* ___________________________________ summary ____________________________________*00:13:13.285* tests: commands succeeded*00:13:13.286* storage-py27: commands succeeded*00:13:13.286* storage-py36: commands succeeded*00:13:13.286* lib-py27: commands succeeded*00:13:13.287* lib-py36: commands succeeded*00:13:13.288* network-py27: commands succeeded*00:13:13.290* network-py36: commands succeeded*00:13:13.291* virt-py27: commands succeeded*00:13:13.292* virt-py36: commands succeeded*00:13:13.293* congratulations :) 2. But we fail to collect logs at the end *00:14:35.992* ##########################################################*00:14:35.995* ## Wed Nov 28 17:39:50 UTC 2018 Finished env: fc28:fedora-28-x86_64*00:14:35.996* ## took 764 seconds*00:14:35.997* ## rc = 1*00:14:35.997* ##########################################################*00:14:36.009* ##! ERROR vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv*00:14:36.010* ##! Last 20 log entries: /tmp/mock_logs.Lcop4ZOq/script/stdout_stderr.log*00:14:36.011* ##!*00:14:36.012* journal/b087148aba6d49b9bbef488e52a48752/system.journal*00:14:36.013* tar: journal/b087148aba6d49b9bbef488e52a48752/system.journal: file changed as we read it*00:14:36.014* journal/b087148aba6d49b9bbef488e52a48752/user-1000.journal*00:14:36.015* lastlog*00:14:36.015* libvirt/*00:14:36.015* libvirt/lxc/*00:14:36.015* libvirt/libxl/*00:14:36.016* libvirt/qemu/*00:14:36.016* libvirt/qemu/LiveOS-f920001d-be4e-47ea-ac26-72480fd5be87.log*00:14:36.017* libvirt/uml/*00:14:36.017* ovirt-guest-agent/*00:14:36.017* ovirt-guest-agent/ovirt-guest-agent.log*00:14:36.017* README*00:14:36.018* samba/*00:14:36.018* samba/old/*00:14:36.018* sssd/*00:14:36.018* tallylog*00:14:36.018* wtmp*00:14:36.018* Took 678 seconds*00:14:36.018* ===================================*00:14:36.019* ##!*00:14:36.019* ##! ERROR ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^*00:14:36.019* ##!######################################################## This looks like an issue with vdsm check-patch.sh: function collect_logs { res=$? [ "$res" -ne 0 ] && echo "*** err: $res" cd /var/log tar -cvzf "$EXPORT_DIR/mock_varlogs.tar.gz" * cd /var/host_log tar -cvzf "$EXPORT_DIR/host_varlogs.tar.gz" * } trap collect_logs EXIT Seems that tar fail to collect log if the log is modified while copied, which makes sense. We can ignore errors in tar, since log collection should not fail the build, but I think a better solution is to avoid collecting any logs since vdsm writes its own logs during tests - all the info must be in vdsm log. Here is the list of collected logs: *00:13:47.280* + tar -cvzf /home/jenkins/workspace/vdsm_master_check-patch-fc28-x86_64/vdsm/exported-artifacts/mock_varlogs.tar.gz btmp dnf.librepo.log dnf.log dnf.rpm.log faillog glusterfs hawkey.log journal lastlog libvirt openvswitch README tallylog vdsm_tests.log wtmp yum.log*00:13:47.285* btmp*00:13:47.285* dnf.librepo.log*00:13:47.299* dnf.log*00:13:47.309* dnf.rpm.log*00:13:47.310* faillog*00:13:47.311* glusterfs/*00:13:47.312* hawkey.log*00:13:47.313* journal/*00:13:47.313* lastlog*00:13:47.315* libvirt/*00:13:47.315* libvirt/qemu/*00:13:47.316* openvswitch/*00:13:47.317* openvswitch/ovs-vswitchd.log*00:13:47.318* openvswitch/ovsdb-server.log*00:13:47.319* README*00:13:47.320* tallylog*00:13:47.321* vdsm_tests.log*00:13:47.342* wtmp*00:13:47.343* yum.log*00:13:47.349* + cd /var/host_log*00:13:47.350* + tar -cvzf /home/jenkins/workspace/vdsm_master_check-patch-fc28-x86_64/vdsm/exported-artifacts/host_varlogs.tar.gz anaconda audit boot.log btmp chrony cloud-init.log cloud-init-output.log cron dnf.librepo.log dnf.log dnf.rpm.log firewalld glusterfs hawkey.log journal lastlog libvirt ovirt-guest-agent README samba sssd tallylog wtmp*00:13:47.356* anaconda/*00:13:47.356* anaconda/ifcfg.log*00:13:47.357* anaconda/ks-script-l5qnynnj.log*00:13:47.358* anaconda/storage.log*00:13:47.359* anaconda/program.log*00:13:47.395* anaconda/ks-script-b5_08tmo.log*00:13:47.396* anaconda/ks-script-6uks8bp3.log*00:13:47.397* anaconda/hawkey.log*00:13:47.398* anaconda/syslog*00:13:47.406* anaconda/journal.log*00:13:47.449* anaconda/dnf.librepo.log*00:13:47.458* anaconda/packaging.log*00:13:47.465* anaconda/dbus.log*00:13:47.466* anaconda/anaconda.log*00:13:47.467* anaconda/ks-script-slrcz39_.log*00:13:47.503* audit/*00:13:47.504* audit/audit.log.3*00:13:47.657* audit/audit.log.2*00:13:47.814* audit/audit.log.1*00:13:47.981* audit/audit.log*00:13:48.008* audit/audit.log.4*00:13:48.155* boot.log*00:13:48.156* btmp*00:13:48.157* chrony/*00:13:48.159* cloud-init.log*00:13:48.159* cloud-init-output.log*00:13:48.161* cron*00:13:48.162* dnf.librepo.log*00:13:49.930* dnf.log*00:13:51.335* dnf.rpm.log*00:13:51.421* firewalld*00:13:51.423* glusterfs/*00:13:51.424* hawkey.log*00:13:51.704* journal/*00:13:51.708* journal/b087148aba6d49b9bbef488e52a48752/*00:13:51.709* journal/b087148aba6d49b9bbef488e52a48752/system.journal*00:13:55.817* tar: journal/b087148aba6d49b9bbef488e52a48752/system.journal: file changed as we read it*00:13:55.819* journal/b087148aba6d49b9bbef488e52a48752/user-1000.journal*00:13:55.915* lastlog*00:13:55.923* libvirt/*00:13:55.924* libvirt/lxc/*00:13:55.926* libvirt/libxl/*00:13:55.927* libvirt/qemu/*00:13:55.928* libvirt/qemu/LiveOS-f920001d-be4e-47ea-ac26-72480fd5be87.log*00:13:55.929* libvirt/uml/*00:13:55.930* ovirt-guest-agent/*00:13:55.930* ovirt-guest-agent/ovirt-guest-agent.log*00:13:55.932* README*00:13:55.933* samba/*00:13:55.933* samba/old/*00:13:55.935* sssd/*00:13:55.935* tallylog*00:13:55.935* wtmp Most if not all are lot relevant to vdsm tests, and should not be collected. This was added in: commit 9c9c17297433e5a5a49aa19cde10b206e7db61e9 Author: Edward Haas <edwardh(a)redhat.com> Date: Tue Apr 17 10:53:11 2018 +0300 automation: Collect logs even when check-patch fails Change-Id: Idfe07ce6fc55473b1db1d7f16754f559cc5c345a Signed-off-by: Edward Haas <edwardh(a)redhat.com> Reviewed in: https://gerrit.ovirt.org/c/90370 Edward, can you explain why do we need to collect logs during check-patch, and why do we need to collect all the logs in the system? Nir

3 13

[Ovirt] [CQ weekly status] [21-12-2018]
by Dafna Ron 21 Dec '18

21 Dec '18

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 (#3) Last job failure was on Dec 11th (i.e no failures reported in the last 10 days for 4.2) *CQ-Master:* RED (#1) Project: ALL Reason: we have an active regression: https://ovirt-jira.atlassian.net/browse/OVIRT-2634 Fix has been merged and waiting to pass CQ: https://gerrit.ovirt.org/#/c/96371/ Please note: Due to the shut down and holidays, the next report will be sent on Jan 11th Happy Holidays! 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

planned datacenter maintenance 21.12.2018 20:30 UTC
by Evgheni Dereveanchin 20 Dec '18

20 Dec '18

Hi everyone, The network switch stack used by the oVirt PHX datacenter needs a reboot which is scheduled for tomorrow. It is expected to be a fast task yet it may cut all networking including shared storage access for all of our hypervisors for a couple of minutes. For this reason I'll shut down non-critical services beforehand and pause CI to minimize I/O activity and protect against potential VM disk corruption. Maintenance window: 21.12.2018 20:30 UTC - 21:30 UTC Services that may be unreachable for short periods of time during this outage are: * Package repositories * Glance image repository * Jenkins CI Other services such as the website, gerrit and mailing lists are not affected and will be operating as usual. -- Regards, Evgheni Dereveanchin

1 0

Failure while trying to setup master
by Shani Leviim 20 Dec '18

20 Dec '18

Hi, I've fetched & rebased ovirt-engine master, but got into this error message while trying to run the setup: [ ERROR ] schema.sh: FATAL: Cannot execute sql command: --file=/home/sleviim/ovirt-engine/share/ovirt-engine/dbscripts/upgrade/04_03_0590_remove_maintenance_and_optional_reason_required.sql [ ERROR ] Failed to execute stage 'Misc configuration': Engine schema refresh failed Can anyone assist, please? *Regards,* *Shani Leviim*

2 1

Adding multiple VM NICs or VM tags in a single request
by Mahesh Falmari 20 Dec '18

20 Dec '18

Hi Nir and RedHat Team, Would like to confirm if it is possible to create multiple VM tags or multiple VM NICs in a single POST request. Currently, I could see that a single request creates a single VM NIC or VM tag for a given virtual machine. We are using the following APIs but looks like it doesn’t allows us to add multiple VM NICs or VM tags in a single request. If it is possible, please let us know how the request body should look like in that case. POST /vms/{vm:id}/tags Request body: <tags> <name>tag1</name> </tags> POST /vms/{vm:id}/nics Request body: <nic> <name>network1</name> </nic> Thanks & Regards, Mahesh Falmari

3 4

[TEST NEEDED] Please test oVirt with Gluster 5
by Sandro Bonazzola 20 Dec '18

20 Dec '18

Hi Sahina, can your team please test oVirt with Gluster 5? Waiting for test results in order to merge https://gerrit.ovirt.org/#/c/95833/ 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>

4 4

Nominate Dominik Holler to have a merge permissions on ovirt-site
by Michael Burman 20 Dec '18

20 Dec '18

Hi All, I would like to suggest the nomination of Dominik Holler to have and get a merge permissions on ovirt-site. Dominik is a professional member and developer in our ovirt community and organization. His contribution to ovirt is huge and i believe that he is an appropriate nomination to receive such permissions. Thank you) -- Michael Burman Senior Quality engineer - rhv network - redhat israel Red Hat <https://www.redhat.com> mburman(a)redhat.com M: 0545355725 IM: mburman <https://red.ht/sig>

3 2

Update to latest master failed with Failed to execute stage 'Setup validation': 'changed'
by Michael Burman 20 Dec '18

20 Dec '18

Hi I'm trying to update the latest master version 4.3.0-0.4.master.20181219115514.git1d803c4.el7 and on engine-setup i get: [ ERROR ] Failed to execute stage 'Setup validation': 'changed' 2018-12-20 08:44:50,803+0200 DEBUG otopi.context context._executeMethod:128 Stage validation METHOD otopi.plugins.ovirt_engine_common.base.core.uninstall.Plugin._validatio n_changed_files 2018-12-20 08:44:50,819+0200 DEBUG otopi.context context._executeMethod:143 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-common/base/core/uninstall.py", line 247, in _validation_changed_files if info['changed'] KeyError: 'changed' 2018-12-20 08:44:50,821+0200 ERROR otopi.context context._executeMethod:152 Failed to execute stage 'Setup validation': 'changed' Known issue? Thanks, -- Michael Burman Senior Quality engineer - rhv network - redhat israel Red Hat <https://www.redhat.com> mburman(a)redhat.com M: 0545355725 IM: mburman <https://red.ht/sig>

2 3

Fwd: oVirt infra weekly meeting notes 19.12.2018
by Eyal Edri 19 Dec '18

19 Dec '18

---------- Forwarded message --------- From: Evgheni Dereveanchin <ederevea(a)redhat.com> Date: Wed, Dec 19, 2018 at 3:39 PM Subject: oVirt infra weekly meeting notes 19.12.2018 To: infra <infra(a)ovirt.org> Hi everyone, Please find this week's infra updates below: PHX: - Jenkins - Core and plugins updated - JVM optimizations enabled - SSE gateway mem leak still not fixed - Dropping sessions from /monitoring helps with load - RAM upgraded on 4 bare metals, 6 to go - oVirt 4.2.7 upgrade started OSAS: - Network issues in community cage still being investigated AI: - Review hawkular in OpenShift - Review SSL facilities for OpenShift -- Regards, Evgheni Dereveanchin _______________________________________________ Infra mailing list -- infra(a)ovirt.org To unsubscribe send an email to infra-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/ZNUMSNQKXNSP2… -- Eyal edri MANAGER RHV/CNV DevOps EMEA VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

1 0

planned Jenkins restart
by Evgheni Dereveanchin 19 Dec '18

19 Dec '18

Hi everyone, I'll be performing a planned Jenkins restart within the next hour. No new jobs will be scheduled during this maintenance period. I will inform you once it is over. Regards, Evgheni Dereveanchin

1 1

[Ovirt] [CQ weekly status] [14-12-2018]
by Dafna Ron 16 Dec '18

16 Dec '18

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 job failure was on Dec 11th. Project: ovirt-engine Reason: infra related failure *CQ-Master:* GREEN (#1) Last job failure was on Dec 13th Project: vdsm Reason: failed package build cause CQ to fail to run. the package build failure was infra related and a new package was successfully built and tested after this failure. 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 1

4.2 CI failure on qemu-io tests
by Milan Zamazal 14 Dec '18

14 Dec '18

Hi, I've seen a CI failure on qemu-io tests in ovirt-4.2 branch: http://jenkins.ovirt.org/job/vdsm_standard-check-patch/602/ It fails only in some testing parts, while in others it succeeds: http://jenkins.ovirt.org/job/vdsm_4.2_check-patch-el7-x86_64/553/ Nir, could you please take a look whether we need to backport your fix from master and/or fix anything else (such as ensuring the right QEMU version is used)? Thanks, Milan

2 3

Questions for Redhat team
by Suchitra Herwadkar 13 Dec '18

13 Dec '18

Hi Nir & RedHat team 1. Cloned VM support in RHV. There are two types of clones as per my understanding 1. Full Cloned VM: Independent copy of a virtual machine that shares nothing with the parent template after the cloning operation. 2. Dependent Cloned VM: It is a copy of a virtual machine that shares virtual disks with the parent template. This type of clone is made from a snapshot of the parent which is qcow2 image. All files available on the parent at the moment of the snapshot continue to remain available to the linked clone. Ongoing changes to the virtual disk of the parent do not affect the linked clone, and changes to the disk of the linked clone do not affect the parent. We want to know what the customer preference ( 1 or 2) as both have pros & cons. What is the guidance given by RHV around this? How do we recommend customers to patch the template disks when multiple VMs are cloned from it? Kindly provide more details. 1. Is there a way to we can mount a QCOW2 image using QCOW2 mounter and have a block level view of the data ? We read about libguestfs but this is filesystem view. 1. We would like to know when we can expect “Allocation Regions API” . I’m referring to https://bugzilla.redhat.com/show_bug.cgi?id=1622946 This is marked for 4.3 at this point in time. I presume we will get it as part of 4.2.X release as well. Kindly confirm ? Thanks Suchitra From: pchavva(a)redhat.com When: 8:30 PM - 9:00 PM December 13, 2018 Subject: [EXTERNAL] Canceled event: RHV- Veritas Netbackup Weekly Sync @ Thu Dec 13, 2018 10am - 10:30am (EST) (suchitra.herwadkar(a)veritas.com) This event has been canceled. RHV- Veritas Netbackup Weekly Sync When Thu Dec 13, 2018 10am – 10:30am Eastern Time - New York Calendar suchitra.herwadkar(a)veritas.com Who • pchavva(a)redhat.com - organizer • mahesh.falmari(a)veritas.com • abhay.marode(a)veritas.com • nsoffer(a)redhat.com • ketan.pachpande(a)veritas.com • tnisan(a)redhat.com • sudhakar.paulzagade(a)veritas.com • suchitra.herwadkar(a)veritas.com • navin.tah(a)veritas.com • ehowriga(a)redhat.com • james.olson(a)veritas.com • adbarbos(a)redhat.com - optional • renee.carlisle(a)veritas.com - optional Agenda: This Engineering weekly sync will cover the engagement activity for Netbackup and RHV integration. To join the Meeting: https://bluejeans.com/5723877297<https://www.google.com/url?q=https%3A%2F%2Fbluejeans.com%2F5723877297&sa=D&…> To join via Room System: Video Conferencing System: <https://www.google.com/url?q=http%3A%2F%2Fredhat.bjn.vc&sa=D&ust=1545134436…> redhat.bjn.vc<https://www.google.com/url?q=http%3A%2F%2Fredhat.bjn.vc&sa=D&ust=1545134436…> -or-199.48.152.18 Meeting ID : 5723877297 To join via phone : 1) Dial: 408-915-6466 (United States) (see all numbers - <https://www.google.com/url?q=https%3A%2F%2Fwww.redhat.com%2Fen%2Fconference…> https://www.redhat.com/en/conference-numbers<https://www.google.com/url?q=https%3A%2F%2Fwww.redhat.com%2Fen%2Fconference…>) 2) Enter Conference ID : 5723877297 Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account suchitra.herwadkar(a)veritas.com because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More<https://support.google.com/calendar/answer/37135#forwarding>.

2 1

Announcing 'COVERAGE' option in OST
by Marcin Sobczyk 13 Dec '18

13 Dec '18

Hi, I've been working on adding coverage report for VDSM in OST recently, and I'm happy to announce, that the first batch of patches is merged! To run a suite with coverage, look for 'COVERAGE' drop-down on OST's build parameters page. If you run OST locally, pass a '--coverage' argument to 'run_suite.sh'. Currently, coverage works only for VDSM in basic-suite-master, but adding VDSM support for other suites is now a no-brainer. More patches are on the way! Since the option is named 'COVERAGE', and not 'VDSM_COVERAGE', other projects are welcome to implement their coverage reports on top of it. Cheers, Marcin

9 8

ovirt-system-tests_compat-4.2-suite-master is failing since November 27
by Sandro Bonazzola 12 Dec '18

12 Dec '18

hi, ovirt-system-tests_compat-4.2-suite-master is failing since November 27 with following error: Error: Fault reason is "Operation Failed". Fault detail is "[Bond name 'bond_fancy0' does not follow naming criteria. For host compatibility version 4.3 or greater, custom bond names must begin with the prefix 'bond' followed by 'a-z', 'A-Z', '0-9', or '_' characters. For host compatibility version 4.2 and lower, custom bond names must begin with the prefix 'bond' followed by a number.]". HTTP response code is 400. I think that if the scope of the test is to check that 4.2 still works with 4.3 engine, bond_fancy0 works for 4.3 but it's clearly not good for 4.2 and the test needs a fix. -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

6 11

Request for reviews
by Germano Veit Michel 12 Dec '18

12 Dec '18

Hi, I would like to have these 2 trivial changes reviewed and merged in time for 4.3 vdsm. Please have a look: https://gerrit.ovirt.org/#/q/topic:dump-volume-chains+(status:open+OR+statu… Thanks, Germano

1 0

v2v: -o rhv-upload: Upload via NBD
by Nir Soffer 11 Dec '18

11 Dec '18

I posted this patch for vdsm, adding NBD APIs: https://gerrit.ovirt.org/c/96079/ The main purpose of these APIs are enabling incremental restore, but they also enable a more efficient rhv-upload via NBD, and importing to thin disks, which is not possible with current solution. The same idea can work for KubeVirt or other targets, minimizing specific target code. Here is how rhv-upload can work using NBD: 1. rhv-upload plugin separated to pre and post scripts - pre - prepare disk and start image transfer - post - finialize image transfer, create vm, etc. 2. rhr-upload-pre plugin create a transfer with transport="nbd" POST /imagetransfers <image_transfer> <disk id="123"/> <direction>upload</direction> <format>raw</format> <transport>nbd</transport> </image_transfer> Engine does not implement <transport> yet, but this should be an easy change. This will use the new NBD APIs to export the disk using NBD over unix socket. We can support later also NBD over TLS/PSK. Engine will return NBD url in transfer_url: <transfer_url>nbd:unix:/run/vdsm/nbd/<transfer_uuid>.sock</tansfer_url> 3. v2v use the trasfer_url to start qem-img with the NBD server: nbdkit (vddk) -> qemu-img convert -> qemu-nbd Note that nbdkit is removed from the rhv side of the pipeline. This is expected to improve the throughput significantly, since imageio is not very good with lot of small requests generated by qemu-img. 4. rhv-upload-post script invoked to complete the transfer What do you think? Nir

2 2

[VDSM] Incremental backup - vdsm NBD APIs
by Nir Soffer 11 Dec '18

11 Dec '18

I posted patches for vdsm new NBD APIs: https://gerrit.ovirt.org/q/topic:nbd+project:vdsm For the big picture, see the feature page: https://ovirt.org/develop/release-management/features/storage/incremental-b… Changes: - Adding option to run a service as user:group https://gerrit.ovirt.org/c/96077 - Adding back support for systemd-run and systemctl_stop to supervdsm. https://gerrit.ovirt.org/c/96078 - Introducing the NBD APIs https://gerrit.ovirt.org/c/96079 - Starting nbd module tests https://gerrit.ovirt.org/c/96080 - Allow running tests that need supervdsm on your laptop https://gerrit.ovirt.org/c/96081 The infrastructure changes may be useful for other maintainers. Please review, Nir

1 1

ovirt-engine has been tagged (ovirt-engine-4.2.8.1)
by Tal Nisan 10 Dec '18

10 Dec '18

1 0

vdsm has been tagged (v4.20.45)
by Milan Zamazal 10 Dec '18

10 Dec '18

1 0

Lago v0.45 Release Announcement
by Gal Ben Haim 10 Dec '18

10 Dec '18

Hi All, On behalf of the Lago team, I'm pleased to announce Lago v0.45 is available! For a detailed release announcement please refer to our Github page at: https://github.com/lago-project/lago/releases/tag/0.45 Resources ========== Lago Docs: http://lago.readthedocs.io/en/latest/ GitHub: https://github.com/lago-project/lago/ YUM Repository: http://resources.ovirt.org/repos/lago/stable/0.0/rpm/ Pypi: https://pypi.python.org/pypi/lago Docker Hub: https://hub.docker.com/r/lagoproject/lago/ Changelog: https://lago.readthedocs.io/en/latest/_static/ChangeLog.txt As always, if you find any problems, or willing to contribute, visit our GitHub page. Enjoy! -- *GAL BEN HAIM* RHV DEVOPS -- *GAL bEN HAIM* RHV DEVOPS

1 0

[Ovirt] [CQ weekly status] [07-12-2018]
by Dafna Ron 07 Dec '18

07 Dec '18

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*: YELLOW (#1) The main issues were packaging issues 1. we needed to replace the 7.6 image due to segmentation faults during add_host. 2. missing dependencies for qemu-kvm-ev - fixed with patch: https://gerrit.ovirt.org/#/c/96055/ *CQ-Master:* YELLOW (#1) 1. we needed to replace the 7.6 image due to segmentation faults during add_host (same as 4.2) 2. vdsm project moved to STDCI v2 which caused failures due to check-patch job which has been failing for a while. although it created failures, vdsm still continued running the V1 jobs which meant tested repo still had updated vdsm packages. 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

Fwd: [CentOS-announce] Announcing the release of Gluster 5 on CentOS Linux 7 x86_64
by Sandro Bonazzola 06 Dec '18

06 Dec '18

fyi ---------- Forwarded message --------- From: Niels de Vos <ndevos(a)redhat.com> Date: gio 6 dic 2018, 20:00 Subject: [CentOS-announce] Announcing the release of Gluster 5 on CentOS Linux 7 x86_64 To: <centos-announce(a)centos.org> I am happy to announce the General Availability of Gluster 5 for CentOS 7 on x86_64. These packages are following the upstream Gluster Community releases, and will receive monthly bugfix updates. Gluster 5 is expected to receive updates until the end of October 2019. The maintanance and release schedule can be found at: https://www.gluster.org/community/release-schedule/ Users of CentOS 7 can now simply install Gluster 5 with only these two commands: # yum install centos-release-gluster # yum install glusterfs-server The centos-release-gluster package is delivered via CentOS Extras repos. This contains all the metadata and dependency information, needed to install Gluster 5. The actual package that will get installed is centos-release-gluster5. Users of Gluster 4.1 can stay on that release until June 2019. Users of Gluster 4.0 and earlier will need to manually upgrade by uninstalling the centos-release-gluster-legacy package, and replacing it with either the Gluster 5 or 4.1 version. Additional details about the upgrade process are linked in the announcement from the Gluster Community: https://lists.gluster.org/pipermail/announce/2018-October/000115.html We have a quickstart guide specifically built around the packages are available, it makes for a good introduction to Gluster and will help get you started in just a few simple steps, this quick start is available at https://wiki.centos.org/SpecialInterestGroup/Storage/gluster-Quickstart More details about the packages that the Gluster project provides in the Storage SIG is available in the documentation: https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster The centos-release-gluster* repositories offer additional packages that enhance the usability of Gluster itself. Utilities and tools that were working with previous versions of Gluster are expected to stay working fine. If there are any problems, or requests for additional tools and applications to be provided, just send us an email with your suggestions. The current list of packages that is (planned to become) available can be found here: https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster/Ecosystem-pkgs We welcome all feedback, comments and contributions. You can get in touch with the CentOS Storage SIG on the centos-devel mailing list (https://lists.centos.org ) and with the Gluster developer and user communities at https://www.gluster.org/mailman/listinfo , we are also available on irc at #gluster on irc.freenode.net, and on twitter at @gluster . Cheers, Niels de Vos Storage SIG member & Gluster maintainer _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org https://lists.centos.org/mailman/listinfo/centos-announce

1 0

[ANN] oVirt 4.3.0 Second Alpha Release is now available for testing
by Sandro Bonazzola 06 Dec '18

06 Dec '18

The oVirt Project is pleased to announce the availability of the Second Alpha Release of oVirt 4.3.0, as of December 6th, 2018 This is pre-release software. This pre-release should not to be used in production. Please take a look at our community page[1] to learn how to ask questions and interact with developers and users. All issues or bugs should be reported via oVirt Bugzilla[2]. This update is the second alpha release of the 4.3.0 version. This release brings more than 80 enhancements and more than 330 bug fixes on top of oVirt 4.2 series. What's new in oVirt 4.3.0? * Q35 chipset, support booting using UEFI and Secure Boot * Skylake-server and AMD EPYC support * New smbus driver in windows guest tools * Improved support for v2v * Tech preview for oVirt on Fedora 28 * Hundreds of bug fixes on top of oVirt 4.2 series * New VM portal details page (see a preview here: https://imgur.com/a/ExINpci) * New Cluster upgrade UI * OVN security groups * IPv6 (static host addresses) * LLDP Labeler * Support for 3.6 and 4.0 data centers, clusters and hosts were removed * Now using PostgreSQL 10 This release is available now on x86_64 architecture for: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later * oVirt Node 4.3 (available for x86_64 only) Experimental tech preview for x86_64 and s390x architectures for Fedora 28 is also included. See the release notes draft [3] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available for both CentOS 7 and Fedora 28 (tech preview). - oVirt Node NG is already available for both CentOS 7 - oVirt Node NG for Fedora 28 (tech preview) is facing build issues on Jenkins and will be released as soon as possible Additional Resources: * Read more about the oVirt 4.3.0 release highlights: http://www.ovirt.org/release/4.3.0/ * Get more oVirt project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] https://www.ovirt.org/community/ [2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt [3] http://www.ovirt.org/release/4.3.0/ [4] http://resources.ovirt.org/pub/ovirt-4.3-pre/iso/ -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

More logs from VNC/qemu/SASL
by Tomasz Barański 06 Dec '18

06 Dec '18

Hello I'm working on supporting VNC console on FIPS-enabled hosts[1]. I made qemu use SASL as authentication method instead of regular passwords. However, no matter what I do, I can't get it to accept credentials provided with a VNC client. Is there a way to get some qemu/SASL logs? I need to understand why the credentials are not accepted. Tomo [1] https://bugzilla.redhat.com/show_bug.cgi?id=1595536

1 0

[VDSM] check-merged failing for years - remove it?
by Nir Soffer 06 Dec '18

06 Dec '18

vdsm check-merged job takes 1.5 hours, and fails 80% of the time. https://jenkins.ovirt.org/job/vdsm_master_check-merged-el7-x86_64/buildTime… Nobody checks these failures or care about them. We are abusing CI resources for no benefit. Can we remove this job? Nir

6 10

planned Jenkins restart
by Evgheni Dereveanchin 06 Dec '18

06 Dec '18

Hi everyone, I'll be performing a planned Jenkins restart within the next hour. No new jobs will be scheduled during this maintenance period. I will inform you once it is over. Regards, Evgheni Dereveanchin

1 1

vdsm has been tagged (v4.30.4)
by Francesco Romani 05 Dec '18

05 Dec '18

_______________________________________________ Devel mailing list -- devel(a)ovirt.org To unsubscribe send an email to devel-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/WUM4SIORNY5RN…

1 0

ovirt-engine has been tagged (ovirt-engine-4.3.0_alpha2)
by Tal Nisan 05 Dec '18

05 Dec '18

1 0

[OST] HE basic suite failing on reposync
by Ales Musil 05 Dec '18

05 Dec '18

Hello, I am trying to run locally he-basic-ansible-suite-master but it keeps failing on reposync: reposync command failed for repoid: ovirt-appliance-master-el7 Any idea what could be wrong? Thank you. Regards, Ales -- ALES MUSIL Associate Software Engineer - rhv network Red Hat EMEA <https://www.redhat.com/> amusil(a)redhat.com IM: amusil <https://red.ht/sig>

3 4

jenkins dead or barely alive?
by Michal Skrivanek 05 Dec '18

05 Dec '18

Hey, it didn’t work well yesterday evening (taking 10+ minutes to trigger CI) and this morning it’s even worse. Logging in to trigger it manually takes ~5 minutes, every action there seems to take ages... Thanks, michal

2 1

[IMPORTANT] Upgrading to PG 10.x in version 4.3 on f28/CentOS7.5 , instructions for developers,, please read before you re-base on master
by Eli Mesika 05 Dec '18

05 Dec '18

Hi We will merge a patch[1] today that will require the upcoming 4.3 version to use Postgres 10 on f28 and Postgres SCL 10 (Software Collections) on CentOS 7.5 * If you are using f28 and creating new DB schema for development (having no 9.x PG data), then you done and this change should be transparent to you. * If you are using f27, have some old 9.x PG data and upgrade to f28, then you will have to upgrade your old PG data after moving to f28 according to the instructions in [2] * If you are using CentOS then you are running PG SCL 9.5 and should upgrade to PG SCL 10 1. Upgrade to CentOS 7.5 (insure that you have the SCL repo [3] after upgrade) 2. #yum update -y # insure that your OS has latest patches 3. #service rh-postgresql95-postgresql stop 4. #yum install rh-postgresql10 rh-postgresql10-postgresql-contrib -y 5. #/opt/rh/rh-postgresql10/root/bin/postgresql-setup --upgrade --upgrade-from="rh-postgresql95-postgresql" # If you have junk sachems, drop them first, the upgrade of each takes time. 6. #service rh-postgresql10-postgresql start # check status to see that it is active 7. #service rh-postgresql10-postgresql enable 8. Insure that your patches are re-based on master latest 9. Remove all <target> binaries created with "#make clean install-dev PREFIX=<target>....." 10. Compile(make install-dev..)/Setup(engine-setup) and run again your patches (git branches you are working on) 11. Insure that basic operations (add new dc/cluster for example) are working 12. Track engine.log / server.log and PG logs for database errors 13. # yum remove rh-postgresql95 rh-postgresql95-postgresql-contrib -y (only if all above is succeed) [1] https://gerrit.ovirt.org/#/c/95100/ [2] https://docs.bmc.com/docs/btco113/migrating-the-data-from-postgresql-9-x-to… [3] https://wiki.centos.org/AdditionalResources/Repositories/SCL If you are developing from a VM then it is always recommended to create a "before upgrade" snapshot of the VM. (I know it is not supported from the user portal but you can ask for access rights only for doing this from your admin on the admin portal. If you have any questions/problems , please contact me Eli Mesika (emesika on IRC) Best Regards Eli

3 2

oVirt PPC support
by Alexandre Bencz 04 Dec '18

04 Dec '18

Hi I have a IBM Power7 machine, I saw that oVirt support is for PPC8, but, I would like to know if it is possible to use oVirt in PowerPC 7, if there is any internal limitation on the implementation of oVirt to not work in PPC7

1 0

Failing OST patches
by Kaustav Majumder 04 Dec '18

04 Dec '18

Recently I have pushed 2 patches for OST[1][2], both are failing in CI. Though unrelated failures I find the errors in "add_hosts" test beacuse the host is non operation within the asserted time.I have added the link for the jenkins log [3]. [1] https://gerrit.ovirt.org/#/c/95327/ [2] https://gerrit.ovirt.org/#/c/95347/ [3] https://pastebin.com/MVpws4Et Any advice? -- KAUSTAV MAJUMDER ASSOCIATE SOFTWARE ENGINEER Red Hat India PVT LTD. <https://www.redhat.com/> kmajumder(a)redhat.com M: 08981884037 IM: IRC: kmajumder <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> @redhatway <https://twitter.com/redhatway> @redhatinc <https://instagram.com/redhatinc> @redhatsnaps <https://snapchat.com/add/redhatsnaps>

4 6

Re: Any way to make VM Hidden/Locked for access
by Pavan Chavva 04 Dec '18

04 Dec '18

+Ovirt Devel and Adelino. FYI. Best, Pavan. On Wed, Nov 28, 2018 at 8:21 AM Mahesh Falmari <Mahesh.Falmari(a)veritas.com> wrote: > Hi Nir, > > Just wanted to check if there is any way to create a VM through API and > make this VM hidden or locked so that it is not shown/accessible to the > users until we explicitly enable it again. > > The use case here is of VM recovery, where we would like to create a VM > first and wanted to check if there is any issue in VM creation and then > fail in the first phase itself before the actual data transfer takes place. > But the issue we may see here is that once VM gets created, it becomes > accessible to users who may play with it and it would impact the subsequent > recovery operations. > > > > Thanks & Regards, > Mahesh Falmari > > > -- PAVAN KUMAR CHAVVA ENGINEERING PARTNER MANAGER Red Hat pchavva(a)redhat.com M: 4793219099 IM: pchavva

3 2

[Ovirt] [CQ weekly status] [30-11-2018]
by Dafna Ron 02 Dec '18

02 Dec '18

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*: RED (#1) I checked last date ovirt-engine and vdsm passed and moved packages to tested as they are the bigger projects and it was on the 27-11-218. We have been having sporadic failures for most of the projects on test check_snapshot_with_memory. We have deducted that this is caused by a code regression in storage based on the following things: 1.Evgheni and Gal helped debug this issue to rule out lago and infra issue as the cause of failure and both determined the issue is a code regression - most likely in storage. 2. The failure only happens on 4.2 branch. 3. the failure itself is cannot run a vm due to low disk space in storage domain and we cannot see any failures which would leave any leftovers in the storage domain. Dan and Ryan are actively involved in trying to find the regression but the consensus is that this is a storage related regression and* we are having a problem getting the storage team to join us in debugging the issue. * I prepared a patch to skip the test in case we cannot get cooperation from storage team and resolve this regression in the next few days: https://gerrit.ovirt.org/#/c/95889/ *CQ-Master:* YELLOW (#1) We have failures which CQ is still bisecting and until its done we cannot point to any specific failing projects. 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)

7 13

otopi defaults again to python3
by Yedidyah Bar David 02 Dec '18

02 Dec '18

Hi all, As some of you might recall, some time ago we made otopi default to python3, and quickly reverted that, realizing this causes too much breakage. Now things should hopefully be more stable, and I now merged a patch to default to python3 again. Current status: engine-setup works with python3 on fedora. host-deploy works with python3 on fedora, with both engine being on el7 and on fedora. Didn't try on el7, might work as well. hosted-engine --deploy is most likely broken on fedora, but I think it was already broken. We are working on that, but it will require some more time - notably, having stuff from vdsm on python3 (if not fully porting vdsm to python3, which I understand will take even more time). If you want to use python2, you can do that with: OTOPI_PYTHON=/bin/python hosted-engine --deploy On el7, if you manually added python3 (which is not available in the base repos), things will break - use above workaround if needed. Best regards, -- Didi

2 2