4:48 a.m.
Hi All,
During the implementation of the moVirt project [1], a client frontend communicating
with the oVirt engine purely via REST-API, many shortcomings of this approach surfaced.
Namely:
* Need for periodic polling: absence of any push notifications
(especially bad for monitoring clients whose main purpose is to
display current dashboard-like overview of the system.)
* Even when polling need to issue excessive amounts of HTTP requests
(list of entities and then have to individually query each entity's sub-resources).
* Very limited and ad-hoc support for data-aggregation
(just VMs' statistics/disks/nics and Hosts' statistics)
* No support for finer grained selection of data client is actually interested in
- always have to fetch full VM entitties only when we are actually interested
in only a handful of fields.
To address the above shortcomings, and improve user experience for our mobile users and
of our future frontend, the Doctor REST project [2] was created to solve the above
concerns
in a generic way that is agnostic of any specific data-format or backend architecture so
it can be used by anyone who wishes to add Doctor's capabilities to their project.
The feature page [3] should track progress of this integration effort and status
of necessary engine patches.
To find more information about the overall design of Doctor REST, please see
the linked wiki page [3], README of the github repo [2] or the attached presentation
that was given to the UX team this summer.
I still need to update the project's README to new overhauled authentication
architecture (designed to work with oVirt SSO), but your questions,
suggestions and other remarks are very welcome.
Thank you and best regards,
Martin Betak
[1] https://github.com/matobet/moVirt
[2] https://github.com/matobet/doctor-rest
[3] http://www.ovirt.org/Features/Doctor_REST