* 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
> 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
> 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
> batch-polling mechanism where an API user passes in a list of task UUIDs
> event URIs. The server would respond with the status of these resources in
> response. I have some ideas on how we could wire up asynchronous events on
> 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)
vdsm-devel mailing list