----- Original Message -----
On Thu, Dec 01, 2011 at 02:02:27AM -0500, Ayal Baron wrote:
----- Original Message -----
-----Original Message----- From: Adam Litke [mailto:agl@us.ibm.com] Sent: Thursday, December 01, 2011 0:41 AM To: vdsm-devel@lists.fedorahosted.org; engine-devel@ovirt.org Cc: Daniel P. Berrange; Chris Wright; Dan Kenigsberg; Itamar Heim Subject: Proposed next-generation vdsm API
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 (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!
Why things non native to REST and wrap it in QMF, rather than do the reverse? Or just to them in parallel, since it sounds like both are going to be first class citizens?
This was more my understanding from our discussion on IRC yesterday.
I'm afraid I did not follow that discussion to your conclusions...
REST API - everything that is relevant for single node management QMF - same API as above + multi-node relevant API calls. I don't see any reason for doing weird things over REST to support the latter.
A QMF broker runs on the vdsm host and talks to the REST API. It connects to a bus and exposes an API to ovirt-engine on this bus using a vdsm-base schema. ovirt-engine wants additional clustering functionality. This API should be implemented completely between the QMF broker and ovirt-engine using a separate vdsm-cluster schema.
In fact, I don't even see any real reason for going through the REST API when using QMF.
Because we want to avoid the proliferation of APIs. I would prefer a mostly vertical chain of API components to a vdsm with several independent APIs (which are sure to diverge or be neglected by individual developers/patches).
If you take a look at today's API you will see that there is nothing there that limits it to XML-RPC and we could easily expose all the calls using REST or anything else. In python, exposing a new verb in the various APIs can be automatic so this would require very little maintenance. Any multi-node or transport specific calls can be decorated as such and would be automatically ignored/picked up by the relevant API layer. This way, we could also easily enable using different bus protocols assuming a customer already has a deployment as was suggested yesterday.
I don't think this will be as automatic as you suggest in practice. It sounds like it will increase code complexity, obfuscation, and maintenance burden.
Even today we don't really have any reliance on the transport. The beauty of REST is its simplicity, but with that come limitations. If we require the qmf API to go through REST then we're basically limiting the qmf to the REST shortcomings or we implement things that bend REST the wrong way to accomodate the extra requirements. For any "simple" call I'm fine with qmf going through REST if it simplifies maintenance, but for things like events, I believe there is no justification for going through REST.
-- Adam Litke agl@us.ibm.com IBM Linux Technology Center