- Devel - oVirt List Archives

[vdsm] tests failures
by Piotr Kliczewski 13 Nov '16

13 Nov '16

All, Few mins ago I saw build [1] failure due to: 13:36:42 ERROR: test_abort_during_copy('block') (storage_sdm_copy_data_test.TestCopyDataDIV) 13:36:42 ---------------------------------------------------------------------- 13:36:42 Traceback (most recent call last): 13:36:42 File "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/testlib.py", line 133, in wrapper 13:36:42 return f(self, *args) 13:36:42 File "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/storage_sdm_copy_data_test.py", line 279, in test_abort_during_copy 13:36:42 raise RuntimeError("Timeout waiting for thread") 13:36:42 RuntimeError: Timeout waiting for thread Thanks, Piotr [1] http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/2326/console

4 4

qemu-kvm-ev 2.6 landing on snapshot repos
by Sandro Bonazzola 13 Nov '16

13 Nov '16

Hi, tonight qemu-kvm-ev 2.6 will land in snapshot repositories for master, 4.0 and 3.6. Please note that you'll need RHEL 7.3 or CentOS 7.3 ( currently ON_QA at http://buildlogs.centos.org/c7.1611.00 ) to use it. qemu-kvm-ev 2.3 is still available in those repos and on CentOS Virt SIG. Jenkins jobs may have failures related to this so please be sure to either filter qemu-kvm-ev 2.6 or versionlock it to 2.3 or add CentOS 7.3 testing repo to the job. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

3 7

Moving oVirt JavaScript application stack forward (short and long term)
by Vojtech Szocs 11 Nov '16

11 Nov '16

Hello, regarding oVirt JavaScript applications (like Dashboard), we'd like to reach a point where we'll be using latest Node.js LTS runtime and lock down all dependency versions, resulting in reproducible builds. Please note that both Node.js and all JS dependencies are needed only when building oVirt JavaScript applications & corresponding packages. The near future items are following: 1, patch ovirt-engine-{nodejs,nodejs-modules} to use Node.js v6 (LTS), refer to https://github.com/nodejs/LTS for more details 2, patch ovirt-engine-nodejs-modules to use Node.js runtime provided by ovirt-engine-nodejs - revive https://gerrit.ovirt.org/#/c/59898/ 3, lock down dependency versions in ovirt-engine-nodejs-modules via npm-shrinkwrap - finalize https://gerrit.ovirt.org/#/c/61957/ >From this point, we can proceed with long term items: 4, consolidate dependencies across projects: 4a, update react-patternfly: - https://github.com/jtomasek/react-patternfly/ - add common PatternFly components (e.g. out of Dashboard) 4b, update ovirt-ui-components: - https://github.com/matobet/ovirt-ui-components/ - depend on react-patternfly - add oVirt specific components (e.g. out of Dashboard) 4c, update ovirt-engine-nodejs-modules: - depend on ovirt-ui-components 4d, update all oVirt JS projects, like Dashboard - depend on ovirt-ui-components *all* oVirt JS projects should depend on ovirt-ui-components. react-patternfly exists separately to support non-oVirt cases. 5, develop "showcase" webapp as part of react-patternfly repo to ensure it's well-aligned with PatternFly look'n'feel - it would be nice to host the "showcase" webapp somewhere 6, address common problems that arise from using npm-shrinkwrap - deterministic (predictable) dependency resolution - checksum verification to ensure integrity of dependencies - dependency de-duplication (avoid multiple versions) Yarn [1][2] addresses all problems mentioned above. It's still in early development, so I'd wait a bit and see how it matures. Note: ManageIQ UI is already using Yarn [3]. [1] https://code.facebook.com/posts/1840075619545360 [2] https://github.com/yarnpkg/yarn [3] https://github.com/ManageIQ/manageiq-ui-service/pull/296/files Feel free to share your thoughts or concerns. Regards, Vojtech

1 1

Can't add DC with API v4 - client issue
by Yaniv Kaul 10 Nov '16

10 Nov '16

I'm trying on FC24, using python-ovirt-engine-sdk4-4.1.0 -0.0.20161003git056315d.fc24.x86_64 to add a DC, and failing - against master. The client is unhappy: File "/home/ykaul/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py", line 98, in add_dc4 version=sdk4.types.Version(major=DC_VER_MAJ,minor=DC_VER_MIN), File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py", line 4347, in add response = self._connection.send(request) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 276, in send return self.__send(request) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 298, in __send self._sso_token = self._get_access_token() File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 460, in _get_access_token sso_response = self._get_sso_response(self._sso_url, post_data) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 498, in _get_sso_response return json.loads(body_buf.getvalue().decode('utf-8')) File "/usr/lib64/python2.7/json/__init__.py", line 339, in loads return _default_decoder.decode(s) File "/usr/lib64/python2.7/json/decoder.py", line 364, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "/usr/lib64/python2.7/json/decoder.py", line 382, in raw_decode raise ValueError("No JSON object could be decoded") ValueError: No JSON object could be decoded Surprisingly, I now can't find that RPM of this SDK in resources.ovirt.org now. I've tried with http://resources.ovirt.org/pub/ovirt-master-snapshot/rp m/fc24/x86_64/python-ovirt-engine-sdk4-4.0.0-0.1.20161004git f94eeb5.fc24.x86_64.rpm - same result. Did not see anything obvious on server or engine logs. The code: def add_dc4(api): nt.assert_true(api != None) dcs_service = api.system_service().data_centers_service() nt.assert_true( dc = dcs_service.add( sdk4.types.DataCenter( name=DC_NAME4, description='APIv4 DC', local=False, version=sdk4.types.Version(major=DC_VER_MAJ,minor=DC_VER_ MIN), ), ) ) And the api object is from: return sdk4.Connection( url=url, username=constants.ENGINE_USER, password=str(self.metadata['ovirt-engine-password']), insecure=True, debug=True, )

4 15

OUTAGE: jenkins.ovirt.org is down
by Eyal Edri 10 Nov '16

10 Nov '16

We're experience problems with the jenkins server, and its currently down. We are in the process of understanding the issue and are working to bring it back online, We will update when the service is back online, hopefully shouldn't take long. Infra team.

2 1

[vdsm] Requiring virt-preview again on Fedora 24
by Francesco Romani 09 Nov '16

09 Nov '16

Hi all, For the upcoming ovirt 4.1 release we are going to use features available only in recent libvirt (>= 2.0.0). Those features are available on CentOS/RHEL, but fedora 24 was left again. For this reason we are going to require the virt-preview repo again [1] This patch enables it on our CI: https://gerrit.ovirt.org/#/c/66308/1 Comments welcome +++ [1] https://fedoraproject.org/wiki/Virtualization_Preview_Repository -- Francesco Romani Red Hat Engineering Virtualization R & D Phone: 8261328 IRC: fromani

2 1

Re: [ovirt-devel] [vdsm] Connection refused when talking to jsonrpc
by Michal Skrivanek 09 Nov '16

09 Nov '16

> On 08 Nov 2016, at 17:52, Martin Sivak <msivak(a)redhat.com> wrote: > > Hi, > > mom-vdsm.service contains: > > Requires=vdsmd.service > After=vdsmd.service > > So when Shira restarted vdsm, mom was also restarted. > > [journalctl --unit vdsmd] > Nov 08 18:25:27 RHEL7.2Server systemd[1]: Stopping Virtual Desktop > Server Manager... > Nov 08 18:25:27 RHEL7.2Server vdsmd_init_common.sh[3053]: vdsm: > Running run_final_hooks > Nov 08 18:25:27 RHEL7.2Server systemd[1]: Starting Virtual Desktop > Server Manager... > > [journalctl --unit mom-vdsm] > Nov 08 18:17:23 RHEL7.2Server systemd[1]: Starting MOM instance > configured for VDSM purposes... > Nov 08 18:25:16 RHEL7.2Server systemd[1]: Stopping MOM instance > configured for VDSM purposes... > Nov 08 18:25:29 RHEL7.2Server systemd[1]: Started MOM instance > configured for VDSM purposes. > > > But mom then immediately failed with: > > 2016-11-08 18:25:08,008 - mom.RPCServer - INFO - ping() > 2016-11-08 18:25:08,010 - mom.RPCServer - INFO - getStatistics() > 2016-11-08 18:25:17,028 - mom.RPCServer - INFO - RPC Server ending > 2016-11-08 18:25:24,705 - mom.GuestManager - INFO - Guest Manager ending > 2016-11-08 18:25:26,575 - mom.HostMonitor - INFO - Host Monitor ending > > 2016-11-08 18:25:29,869 - mom - INFO - MOM starting > 2016-11-08 18:25:29,905 - mom.HostMonitor - INFO - Host Monitor starting > 2016-11-08 18:25:29,905 - mom - INFO - hypervisor interface vdsmjsonrpcbulk > 2016-11-08 18:25:30,029 - mom.vdsmInterface - ERROR - Cannot connect > to VDSM! [Errno 111] Connection refused > 2016-11-08 18:25:30,030 - mom - ERROR - Failed to initialize MOM threads > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 29, in run > hypervisor_iface = self.get_hypervisor_interface() > File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 217, > in get_hypervisor_interface > return module.instance(self.config) > File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmjsonrpcbulkInterface.py", > line 47, in instance > return JsonRpcVdsmBulkInterface() > File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmjsonrpcbulkInterface.py", > line 29, in __init__ > super(JsonRpcVdsmBulkInterface, self).__init__() > File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmjsonrpcInterface.py", > line 43, in __init__ > .orRaise(RuntimeError, 'No connection to VDSM.') > File "/usr/lib/python2.7/site-packages/mom/optional.py", line 28, in orRaise > raise exception(*args, **kwargs) > RuntimeError: No connection to VDSM. > > > The question here is, how much time does VDSM need to allow jsonrpc to > connect and request a ping and list of VMs? The only correct answer is - when it's ready and responds with success rather than either not respond at all(as in your case) or with "recovering from crash or initializing" code > > > Martin > _______________________________________________ > vdsm-devel mailing list -- vdsm-devel(a)lists.fedorahosted.org > To unsubscribe send an email to vdsm-devel-leave(a)lists.fedorahosted.org > >

2 1

Re: [ovirt-devel] [vdsm] Connection refused when talking to jsonrpc
by Martin Perina 09 Nov '16

09 Nov '16

Adding Piotr On Tue, Nov 8, 2016 at 5:52 PM, Martin Sivak <msivak(a)redhat.com> wrote: > Hi, > > mom-vdsm.service contains: > > Requires=vdsmd.service > After=vdsmd.service > > So when Shira restarted vdsm, mom was also restarted. > > [journalctl --unit vdsmd] > Nov 08 18:25:27 RHEL7.2Server systemd[1]: Stopping Virtual Desktop > Server Manager... > Nov 08 18:25:27 RHEL7.2Server vdsmd_init_common.sh[3053]: vdsm: > Running run_final_hooks > Nov 08 18:25:27 RHEL7.2Server systemd[1]: Starting Virtual Desktop > Server Manager... > > [journalctl --unit mom-vdsm] > Nov 08 18:17:23 RHEL7.2Server systemd[1]: Starting MOM instance > configured for VDSM purposes... > Nov 08 18:25:16 RHEL7.2Server systemd[1]: Stopping MOM instance > configured for VDSM purposes... > Nov 08 18:25:29 RHEL7.2Server systemd[1]: Started MOM instance > configured for VDSM purposes. > > > But mom then immediately failed with: > > 2016-11-08 18:25:08,008 - mom.RPCServer - INFO - ping() > 2016-11-08 18:25:08,010 - mom.RPCServer - INFO - getStatistics() > 2016-11-08 18:25:17,028 - mom.RPCServer - INFO - RPC Server ending > 2016-11-08 18:25:24,705 - mom.GuestManager - INFO - Guest Manager ending > 2016-11-08 18:25:26,575 - mom.HostMonitor - INFO - Host Monitor ending > > 2016-11-08 18:25:29,869 - mom - INFO - MOM starting > 2016-11-08 18:25:29,905 - mom.HostMonitor - INFO - Host Monitor starting > 2016-11-08 18:25:29,905 - mom - INFO - hypervisor interface vdsmjsonrpcbulk > 2016-11-08 18:25:30,029 - mom.vdsmInterface - ERROR - Cannot connect > to VDSM! [Errno 111] Connection refused > 2016-11-08 18:25:30,030 - mom - ERROR - Failed to initialize MOM threads > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 29, in run > hypervisor_iface = self.get_hypervisor_interface() > File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 217, > in get_hypervisor_interface > return module.instance(self.config) > File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/ > vdsmjsonrpcbulkInterface.py", > line 47, in instance > return JsonRpcVdsmBulkInterface() > File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/ > vdsmjsonrpcbulkInterface.py", > line 29, in __init__ > super(JsonRpcVdsmBulkInterface, self).__init__() > File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/ > vdsmjsonrpcInterface.py", > line 43, in __init__ > .orRaise(RuntimeError, 'No connection to VDSM.') > File "/usr/lib/python2.7/site-packages/mom/optional.py", line 28, in > orRaise > raise exception(*args, **kwargs) > RuntimeError: No connection to VDSM. > > > The question here is, how much time does VDSM need to allow jsonrpc to > connect and request a ping and list of VMs? > > > Martin > _______________________________________________ > vdsm-devel mailing list -- vdsm-devel(a)lists.fedorahosted.org > To unsubscribe send an email to vdsm-devel-leave(a)lists.fedorahosted.org >

6 8

Re: [ovirt-devel] [vdsm] Connection refused when talking to jsonrpc
by Nir Soffer 08 Nov '16

08 Nov '16

On Tue, Nov 8, 2016 at 6:52 PM, Martin Sivak <msivak(a)redhat.com> wrote: > Hi, > > mom-vdsm.service contains: > > Requires=vdsmd.service > After=vdsmd.service After does not mean much, since vdsm is not integrated with systemd. Systemd does not wait until vdsm is ready to receive connections. We can use systemd.daemon to notify systemd that vdsm is ready, making dependencies more reliable. See https://github.com/oVirt/ovirt-imageio/blob/master/daemon/ovirt_imageio_dae… > So when Shira restarted vdsm, mom was also restarted. > > [journalctl --unit vdsmd] > Nov 08 18:25:27 RHEL7.2Server systemd[1]: Stopping Virtual Desktop > Server Manager... > Nov 08 18:25:27 RHEL7.2Server vdsmd_init_common.sh[3053]: vdsm: > Running run_final_hooks > Nov 08 18:25:27 RHEL7.2Server systemd[1]: Starting Virtual Desktop > Server Manager... > > [journalctl --unit mom-vdsm] > Nov 08 18:17:23 RHEL7.2Server systemd[1]: Starting MOM instance > configured for VDSM purposes... > Nov 08 18:25:16 RHEL7.2Server systemd[1]: Stopping MOM instance > configured for VDSM purposes... > Nov 08 18:25:29 RHEL7.2Server systemd[1]: Started MOM instance > configured for VDSM purposes. > > > But mom then immediately failed with: > > 2016-11-08 18:25:08,008 - mom.RPCServer - INFO - ping() > 2016-11-08 18:25:08,010 - mom.RPCServer - INFO - getStatistics() > 2016-11-08 18:25:17,028 - mom.RPCServer - INFO - RPC Server ending > 2016-11-08 18:25:24,705 - mom.GuestManager - INFO - Guest Manager ending > 2016-11-08 18:25:26,575 - mom.HostMonitor - INFO - Host Monitor ending > > 2016-11-08 18:25:29,869 - mom - INFO - MOM starting > 2016-11-08 18:25:29,905 - mom.HostMonitor - INFO - Host Monitor starting > 2016-11-08 18:25:29,905 - mom - INFO - hypervisor interface vdsmjsonrpcbulk > 2016-11-08 18:25:30,029 - mom.vdsmInterface - ERROR - Cannot connect > to VDSM! [Errno 111] Connection refused > 2016-11-08 18:25:30,030 - mom - ERROR - Failed to initialize MOM threads > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 29, in run > hypervisor_iface = self.get_hypervisor_interface() > File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 217, > in get_hypervisor_interface > return module.instance(self.config) > File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmjsonrpcbulkInterface.py", > line 47, in instance > return JsonRpcVdsmBulkInterface() > File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmjsonrpcbulkInterface.py", > line 29, in __init__ > super(JsonRpcVdsmBulkInterface, self).__init__() > File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmjsonrpcInterface.py", > line 43, in __init__ > .orRaise(RuntimeError, 'No connection to VDSM.') > File "/usr/lib/python2.7/site-packages/mom/optional.py", line 28, in orRaise > raise exception(*args, **kwargs) > RuntimeError: No connection to VDSM. > > > The question here is, how much time does VDSM need to allow jsonrpc to > connect and request a ping and list of VMs? Even if we fix vdsm, mom (and any other client) should be more robust and do not created so much noise when connection is refused. Client should retry connection and log less dramatic warnings. Adding devel@ovirt, vdsm-devel mailing was abandoned more then 2 years ago. Nir

1 0

Re: [ovirt-devel] [lago-devel] Help debugging HC test failures
by Eyal Edri 08 Nov '16

08 Nov '16

Adding also ovirt devel list On Tue, Nov 8, 2016 at 10:25 AM, Sahina Bose <sabose(a)redhat.com> wrote: > Hi, > > I need some help/pointers to solve the issues I'm running into while > running the gluster HC tests - https://gerrit.ovirt.org/57283 > > 1. Once I run the suite, initialization completes successfully, but > further tests fail. Engine is running as per "hosted-engine --vm-status" on > the first host (lago_basic_suite_hc_host0) and I can ping the engine from > the host running the test > > File "/usr/lib/python2.7/site-packages/ovirtlago/virt.py", line 189, in > get_api > return self.get_api_v3() > File "/usr/lib/python2.7/site-packages/ovirtlago/virt.py", line 195, in > get_api_v3 > self._api_v3 = self._get_api(api_ver=3) > File "/usr/lib/python2.7/site-packages/ovirtlago/virt.py", line 180, in > _get_api > raise RuntimeError('Failed to connect to the engine') > RuntimeError: Failed to connect to the engine > > Which logs should I look at to debug this issue? > > > 2. Cannot access the web url of engine: > I've setup tunnelling: ssh -L hc-engine.lago.local:8443:hc-engine.lago.local:443 > root(a)rhsdev-grafton1.lab.eng.blr.redhat.com > But continue getting the error: > The client is not authorized to request an authorization. It's required to > access the system using FQDN. > > 3. Once the vms are left running for a while, connectivity is lost between > the vms and cannot connect to some of the VMs via lago shell . > > [root@lago_basic_suite_hc_host0 ~]# ping lago_basic_suite_hc_host1 > PING lago_basic_suite_hc_host1 (192.168.200.2) 56(84) bytes of data. > From lago-basic-suite-hc-host0.lago.local (192.168.200.3) icmp_seq=1 > Destination Host Unreachable > > Looks like issue with network in VM from console of VM > deployment-basic_suite_hc]# virsh console a2051d60-lago_basic_suite_hc_ > host1 > Connected to domain a2051d60-lago_basic_suite_hc_host1 > > [root@lago_basic_suite_hc_host1 ~]# ip addr show > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > state UP qlen 1000 > link/ether 54:52:c0:a8:c8:02 brd ff:ff:ff:ff:ff:ff > inet6 fe80::5652:c0ff:fea8:c802/64 scope link > valid_lft forever preferred_lft forever > > > > > Any pointers are much appreciated. > > thanks > sahina > > _______________________________________________ > lago-devel mailing list > lago-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/lago-devel > > -- Eyal Edri Associate Manager RHV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

1 0