[Engine-devel] Announcing a proof of concept REST API for VDSM

[Adam Litke]

On Wed, Nov 30, 2011 at 09:29:23AM +0000, Daniel P. Berrange wrote:
> On Wed, Nov 30, 2011 at 09:14:16AM +0200, Itamar Heim wrote:
> > On 11/29/2011 11:36 PM, Adam Litke wrote:
> > > On Tue, Nov 29, 2011 at 12:54:44PM -0800, Chris Wright wrote:
> > >> * Adam Litke (agl at us.ibm.com) wrote:
> > >>> On Tue, Nov 29, 2011 at 11:39:08AM -0800, Chris Wright wrote:
> > >>>> * Adam Litke (agl at us.ibm.com) wrote:
> > >>>>>
> > >>>>> https://github.com/aglitke/vdsm-rest/
> > >>>>>
> > >>>>> Today I am releasing a proof of concept implementation of a REST API for vdsm.
> > >>>>> You can find the code on github.  My goal is to eventually replace the current
> > >>>>> xmlrpc interface with a REST API.  Once completed, ovirt-engine could switch to
> > >>>>> this new API.  The major advantages to making this change are: 1) VDSM will gain
> > >>>>> a structured API that conceptually, structurally, and functionally aligns with
> > >>>>> the ovirt-engine REST API, 2) this new API can be made public, thus providing an
> > >>>>> entry point for direct virtualization management at the node level.
> > >>>>
> > >>>> Adam, this looks like a nice PoC.  I didn't see how API versioning is
> > >>>> handled.  Any VDSM developers willing to review this work?
> > >>>
> > >>> Thanks for taking a look.  I am not handling versioning yet.  I think we can add
> > >>> a version field to the root API object.  As for compatibility, we'll just have
> > >>> to decide on an API backwards-compat support policy.  Would this be enough to
> > >>> handle versioning issues?  We shouldn't need anything like capabilities because
> > >>> the API is discoverable.
> > >>
> > >> Right, that seems sensible.
> > >>
> > >> Did you find cases where RPC to REST resource mapping was difficult?
> > >
> > > I haven't yet fully implemented the current vdsm API but I suspect that certain
> > > calls (like the ones you mention below) will require some extensions to what I
> > > have available currently.  The main missing piece is probably events and a nice
> > > polling API.  Another big piece of work will be to rebase onto the newly
> > > redesigned storage model.
> > >
> > >> I could see something like migrate() plus migrateStatus() and
> > >> migrateCancel() needing to add some kind of operational state that to the
> > >> resource.  And something like monitorCommand() which has both a possible
> > >> side-effect and some freefrom response...
> > >
> > > Hopefully monitorCommand will not be too bad, since vdsm should be asking
> > > libvirt for the VM details when they are needed.  Of course we'll need to be
> > > testing to make sure we aren't keeping state around.  Also, I would expect
> > > monitorCommand to 'taint' the VM in the eyes of the vdsm API (as it does for
> > > libvirt).
> > >
> > >>>> <snip>
> > >>>>> ovirt-engine wants to subscribe to asynchronous events.  REST APIs do not
> > >>>>> typically support async events and instead rely on polling of resources.  I am
> > >>>>> investigating what options are available for supporting async events via REST.
> > >>>>
> > >>>> I think typical is either polling or long polling.  If it's a single
> > >>>> resource, then perhaps long polling would be fine (won't be a large
> > >>>> number of connections tied up if it's only a single resource).
> > >>>
> > >>> Not sure if this is what you are referring to, but I was thinking we could do a
> > >>> batch-polling mechanism where an API user passes in a list of task UUIDs and/or
> > >>> event URIs.  The server would respond with the status of these resources in one
> > >>> response.  I have some ideas on how we could wire up asynchronous events on the
> > >>> server side to reduce the amount of actual work that such a batch-polling
> > >>> operation would require.
> > >>
> > >> Oh, I just meant this:
> > >>
> > >> Polling (GET /event + 404 loop)
> > >> Long polling (GET + block ... can chew up a thread connection)
> > >
> > > Yep.  And we can talk later about building an API for efficient, repeated
> > > polling.  I wonder if the ovirt-engine guys could weigh in as to whether a REST
> > 
> > cc-ing engine-devel...
> > 
> > > interface with event polling would be acceptable to them.  It is critical that
> > > we settle on an API that can become _the_ first-class vehicle for interacting
> > > with vdsm.
> > 
> > i have two points for consideration around this:
> > 1. as the api between ovirt-engine and vdsm, I had a preference for the 
> > bus like nature of QMF, as it would allow multiple ovirt-engine to load 
> > balance handling of messages from the queue, and multiple consumers for 
> > some messages (say, history service picking up the stats in parallel to 
> > engine picking them, rather than copying them from engine).
> 
> I tend to agree, using a bus like QMF between ovirt-engine and vdsm is
> an inherantly more scalable network architecture, since it avoids the
> need to have a direct point-to-point connection between the engine and
> every single node, instead you can build a resilient grid by stategically
> deploying QPid brokers.
> 
> As compared to REST, it is also much better at coping with async events,
> since you can have a push, rather than pull, model which VDSM just puts
> events onto the bus as they're generated, to be lazily consumed by any
> remote nodes when desired.
> 
> NB, I don't mean to imply that there should not *also* be a REST API for
> the node level. A REST API has the very compelling property that it is
> trivially accessible from anything with HTTP client support, which is
> basically everything in existance today.

My goal is to create a single first-class VDSM API that both ovirt-engine and
external applications can use.  I am ok with checking out QMF as long as it is
distro agnostic and relatively light-weight.  In that case, someone (maybe me)
could always write a REST interface, but it would merely consume the first-class
QMF API.  I want to avoid having multiple, parallel APIs to maintain.

> > 2. as node level api, i think a lightweight ovirt-engine managing a 
> > single node and exposing the exact same REST API and behavior of the 
> > multi-node ovirt engine would be easier to cosnume for someone that 
> > wants to interact with a single node same way they would interact with 
> > ovirt-engine.
> 
> If the REST API is well specified, you wouldn't need to necessarily have
> a lightweight ovirt-engine deployed at the node level, you could just
> have VDSM implement the same REST specification natively, as is impl
> in the engine. Or perhaps provide a some shered code that can be plugged
> into both VDSM & the enegine to facilitate provision of the same REST
> interface.

Code sharing is hard between the engine and vdsm because the former is Java/C#
and vdsm is python.  It might be fine to simply expose a single QMF (or
whatever) API from vdsm and let some better vdsm interface tools evolve from
that (command-line shell, web UI, native app).

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