* Adam Litke (a...@us.ibm.com) wrote:
> On Tue, Nov 29, 2011 at 11:39:08AM -0800, Chris Wright wrote:
> > * Adam Litke (a...@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@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 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...

> > <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)

thanks,
-chris
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to