----- Original Message -----
> > -----Original Message-----
> > From: Adam Litke [mailto:a...@us.ibm.com]
> > Sent: Thursday, December 01, 2011 0:41 AM
> > To: email@example.com; engine-de...@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
> > 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
> > Create a REST API that will provide all of the functionality that
> > is
> > 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
> > 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.
> > 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
> Or just to them in parallel, since it sounds like both are going to
> 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
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
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 mailing list