[Engine-devel] Proposed next-generation vdsm API

[Adam Litke]

On Thu, Dec 01, 2011 at 02:02:27AM -0500, Ayal Baron wrote:
> 
> 
> ----- Original Message -----
> > 
> > 
> > > -----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?
> 
> 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.

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