Re: [Engine-devel] Proposed next-generation vdsm API

----- Original Message ----- > > > > -----Original Message----- > > From: Adam Litke [mailto:agl@us.ibm.com] > > Sent: Thursday, December 01, 2011 0:41 AM > > To: vdsm-devel(a)lists.fedorahosted.org; engine-devel(a)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.