On 11/30/2011 11:41 AM, Daniel P. Berrange wrote:
> On Tue, Nov 29, 2011 at 12:54:44PM -0800, Chris Wright wrote:
>> * 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)
> Yes, this is what I was inclined to suggest too. Polling is such a
> misleading description :-P
> This isn't really an either/or choice - you could trivially just
> pass a query parmeter to /event to indicate whether you want an
> immediate  404 reply, or to wait for 'N' seconds, or infinity
> There's no reason it needs to consume a thread in VDSM permanently,
> though I don't think that's a huge problem even if it does keep a
> permanent thread open, since Linux threading is so lightweight.
> In more detail, I'd was going to suggest
>    1. One or more location for registering/unregistering interest
>       in events in various different resources/objects
>          /some/path/register-event?foo=bar
>          /some/path/unregister-event?foo=bar
>          /other/path/register-event?eek=oooh
>    2. A common location for receiving all events
>           /event?wait=NNNN   (NNN = 0 =>  immediate 404,
>                               NNN>= 0 =>  wait time,
>                               omitted parameter =>  inifinity)
>    3. Added  bonus points to either
>         - Support persistent keepalive connections so that
>           you can just send further GET /event requests over
>           the same socket FD after receving each reply
>         - Used HTTP chunked encoding. Each event is sent back
>           as a separate chunk. The server can just carry
>           on sending you chunks forever as new events occur,
>           so the HTTP reply is in effect infinitely long.
              - the server would respond with the event status in a 
100-continue response, thus 'lingering' the response for as much as the 
client needs. Less overhead than chunks, just as problematic with crappy 
proxies that do not properly support either chunking or 100-continue 
properly (but should not be an issue if it's within SSL).


> Bonus item 3.2 seems particularly effective to me.
> Regards,
> Daniel

vdsm-devel mailing list

Reply via email to