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(a)us.ibm.com) wrote:
>>>On Tue, Nov 29, 2011 at 11:39:08AM -0800, Chris Wright wrote:
>>>>* Adam Litke (agl(a)us.ibm.com) wrote:
>>>>>Today I am releasing a proof of concept implementation of a REST API
>>>>>You can find the code on github. My goal is to eventually replace
>>>>>xmlrpc interface with a REST API. Once completed, ovirt-engine could
>>>>>this new API. The major advantages to making this change are: 1)
VDSM will gain
>>>>>a structured API that conceptually, structurally, and functionally
>>>>>the ovirt-engine REST API, 2) this new API can be made public, thus
>>>>>entry point for direct virtualization management@the node level.
>>>>Adam, this looks like a nice PoC. I didn't see how API versioning
>>>>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
>>>to decide on an API backwards-compat support policy. Would this be enough
>>>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 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
>>>>>ovirt-engine wants to subscribe to asynchronous events. REST APIs do
>>>>>typically support async events and instead rely on polling of
resources. I am
>>>>>investigating what options are available for supporting async events
>>>>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)
>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
>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
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
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?
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
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.
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center