[Engine-devel] Proposed next-generation vdsm API

[Ayal Baron]

----- 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.
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.
In fact, I don't even see any real reason for going through the REST API when using QMF.
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.

> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel
>