Re: [Engine-devel] Proposed next-generation vdsm API
On 11/30/2011 05:40 PM, Adam Litke wrote:
Recently we've had some very productive discussions concerning
the VDSM API. I
want to attempt to refocus the discussion around an emerging proposal and see if
we can agree on a sensible path forward.
Based on the discussion, I have identified the following requirements that
a new API for vdsm should have:
1.) Single API that can be consumed by ovirt-engine and ISVs
- We don't want to maintain multiple parallel APIs
- To develop a vendor ecosystem, we must have a robust external API to
vdsm
2.) Full vdsm capabilities are exposed without requiring ovirt-engine
- ovirt components should be modular and independently useful
- Some deployments might want to manage nodes without ovirt-engine
3.) Standardized protocol with low overhead
- Required for widespread adoption
4.) Support for asynchronous tasks and events
- Needed by ovirt-engine and other consumers
Based on these requirements, the following proposal has started to emerge:
Create a REST API that will provide all of the functionality that is currently
available via the xmlrpc interface
I just want to stress that it WILL deprecate and
significantly change
some aspects of the API most obvious are the task aspects of the API.
Even though the commands might be the same the current async\sync task
semantics might change to better accommodate the QMF wrapper and other
users. I don't think it's needed to go into details now but I am
stressing that there WILL be API calls the will not migrate or
significantly change in the REST API.
(with the goal of deprecating xmlrpc once it
becomes mature enough). To support advanced clustering features that
ovirt-engine is planning, we'll write an QMF broker that can proxy the REST API
onto a message bus. ovirt-engine will interact with vdsm exclusively over this
bus but the REST API will be the principle API and the entry point for ISV apps.
A REST API provides a light-weight and standard way to access all of the vdsm
functionality.
The REST API will handle events by exposing a new 'events' collection at the api
root. REST users will use some sort of polling to collect these events. The
details of this interface are being worked on. Several ways for minimizing the
impact of polling have been discussed. The QMF broker can expose a
publish/subscribe model for events as appropriate.
Is this model an acceptable way to improve the vdsm API? I would like to hear
the opinions of ovirt-engine developers, vdsm developers, and other
stakeholders. Thanks for providing feedback on this proposal!