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 (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 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.

vdsm-devel mailing list

Reply via email to