On Wed, Nov 30, 2011 at 03:21:07PM +0200, Itamar Heim wrote: > On 11/30/2011 11:29 AM, 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. > > > >>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. > > Indeed, but an API is not just the transport, it is also behavior > and error code numbering, etc. > trying to develop two different projects trying to do the same thing > sounds like quite the overhead to me.
Agreed. > I prefer investing the time in making a lighter version of the > engine for a single node. > then you would also get the web admin and power user portal if you > want them. Could you flesh out some details on the effort required to implement a light-weight engine? I am concerned that this is more complex than it seems. Also, how would we avoid dual maintenance between the full engine and the light one when a new feature/api is added? -- 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
