Moving oVirt JavaScript application stack forward (short and long term)
by Vojtech Szocs
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
8 years
Can't add DC with API v4 - client issue
by Yaniv Kaul
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,
)
8 years
OUTAGE: jenkins.ovirt.org is down
by Eyal Edri
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.
8 years
Re: [ovirt-devel] [vdsm] Connection refused when talking to jsonrpc
by Michal Skrivanek
> 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
>
>
8 years
Re: [ovirt-devel] [vdsm] Connection refused when talking to jsonrpc
by Martin Perina
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
>
8 years
Re: [ovirt-devel] [vdsm] Connection refused when talking to jsonrpc
by Nir Soffer
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_d...
> 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
8 years
Re: [ovirt-devel] [lago-devel] Help debugging HC test failures
by Eyal Edri
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)
8 years
[ANN] Changes to oVirt Bugzilla Process.
by Yaniv Dary
Hi,
In order to make the process lighter and reduce bureaucracy we will be
making the following changes this Sunday (06/11/16):
- *Acks will no longer be needed on bugs, only on RFEs* - This means the
rules engine will not add them and you are not required to get them for
bugs. RFEs will still get acks by rules engine and are required for every
feature.
- *Flags be set automatically according to milestone - *This means you will
no longer need to add flags. The rules engine will do this for you
according to milestone. You will still be able to add flags to mark a bug
to be tested on two branches.
- *The version flag will not differentiate between major version and z
stream - *This change will only apply to 4.1+ flags. For example
ovirt-4.1.0 and ovirt-4.1.z will be merged to ovirt-4.1 flag.
Thanks,
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
8272306
Email: ydary(a)redhat.com
IRC : ydary
8 years
