On Wed, Nov 30, 2011 at 09:29:23AM +0000, Daniel P. Berrange 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. > > > > 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). > > I tend to agree, using a bus like QMF between ovirt-engine and vdsm is > an inherantly more scalable network architecture, since it avoids the > need to have a direct point-to-point connection between the engine and > every single node, instead you can build a resilient grid by stategically > deploying QPid brokers. > > As compared to REST, it is also much better at coping with async events, > since you can have a push, rather than pull, model which VDSM just puts > events onto the bus as they're generated, to be lazily consumed by any > remote nodes when desired. > > NB, I don't mean to imply that there should not *also* be a REST API for > the node level. A REST API has the very compelling property that it is > trivially accessible from anything with HTTP client support, which is > basically everything in existance today.
My goal is to create a single first-class VDSM API that both ovirt-engine and external applications can use. I am ok with checking out QMF as long as it is distro agnostic and relatively light-weight. In that case, someone (maybe me) could always write a REST interface, but it would merely consume the first-class QMF API. I want to avoid having multiple, parallel APIs to maintain. > > 2. as node level api, i think a lightweight ovirt-engine managing a > > 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. > > If the REST API is well specified, you wouldn't need to necessarily have > a lightweight ovirt-engine deployed at the node level, you could just > have VDSM implement the same REST specification natively, as is impl > in the engine. Or perhaps provide a some shered code that can be plugged > into both VDSM & the enegine to facilitate provision of the same REST > interface. Code sharing is hard between the engine and vdsm because the former is Java/C# and vdsm is python. It might be fine to simply expose a single QMF (or whatever) API from vdsm and let some better vdsm interface tools evolve from that (command-line shell, web UI, native app). -- Adam Litke <a...@us.ibm.com> IBM Linux Technology Center _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel