[Engine-devel] Proposed next-generation vdsm API

[Adam Litke]

On Wed, Nov 30, 2011 at 11:32:55PM -0500, Itamar Heim wrote:
> 
> 
> > -----Original Message-----
> > From: Adam Litke [mailto:agl at us.ibm.com]
> > Sent: Thursday, December 01, 2011 0:41 AM
> > To: vdsm-devel at lists.fedorahosted.org; engine-devel at 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?

Parallel APIs mean dual maintenance.  There will be inherent incompatibilities
as each API would naturally have small differences.  The reason for beginning
with REST because of its low overhead and simplicity.  Users of the REST API
would not need to concern themselves with QMF at all but if that extra set of
features is desired it can be easily added.

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center