[Engine-devel] Proposed next-generation vdsm API
Adam Litke
agl at us.ibm.com
Thu Dec 1 19:10:53 UTC 2011
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
More information about the Engine-devel
mailing list