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

[Itamar Heim]

On 11/30/2011 05:00 PM, Adam Litke 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.
>>>
>>> Thanks!
>>>
>>
>>
>> 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).
>
> How easy is QMF to consume from a software development perspective?  Would it be
> easy for someone to write a virsh-like tool against a QMF-based vdsm API?  Would
> such a tool be able to run on multiple Linux distributions?

it is supposed to have a cli console.
cc'ing carl and Ted for more details.

>
>> 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.
>
> In principle an ovirt-engine-light sounds great.  Especially if we could get the
> existing GUIs for free.  The main concern I have with this is the gargantuan
> nature of the ovirt-engine and GUI code bases.  You want to reserve as many
> system resources for the guests but it seems that ovirt-engine will consume at
> least several GB of RAM and one or more CPU cores.  How would you lighten up
> this JBoss stack without rewriting it in a more efficient language?  One use
> case I am interested in is a single-node ovirt instance to control VMs on my
> laptop.  I can spare several hundred MB of RAM at most for the management stack.
>

this is much much lighter and faster with jboss7 (which iirc, takes 
100MB to start, tomcat takes 80MB for comparison).
then we can look at modularizing/alternatives if still needed.