On Tue, Dec 06, 2011 at 02:58:59PM +0200, Dan Kenigsberg wrote: > On Mon, Dec 05, 2011 at 11:34:18AM -0600, Adam Litke wrote: > > Hi everyone. On today's VDSM call we discussed the requirements, design, > > and > > plan for updating the API to include support for QMF and single-host REST > > API. > > All members present arrived at a general consensus on the best way to > > design the > > next-generation API. I have tried to capture this discussion in the oVirt > > wiki: > > > > http://ovirt.org/wiki/Vdsm_API > > > > Please take a look at this page and let's discuss any changes that may be > > needed > > in order to adopt it as a working plan that we can begin to execute. > > Thanks! > > > > Very nice, I've fixed two bullets about the future of the xml-rpc.
Thanks... Updates look good to me. > I think that we are missing something here: how do we model Vdsm-to-Vdsm > communication, in a binding-blind way? I'm less worried about the > storage-based mailbox used for lvextend requests: my problem is with > migration command. Ok, interesting... Besides migration, are there other features (current or planned) that would involve P2P communication? I want to ensure we consider the full problem space. > Currently, the implementation of the "migrate" verb includes contacting > the remote Vdsm over xml-rpc before issuing the libvirt migrateToURI2 > command ('migrationCreate' verb). > > A Vdsm user who choose to use the REST binding, is likely to want this to > be implemented this using a REST request to the destination. This means > that the implementation of Vdsm depends on the chosen binding. > > The issue can be mitigating by requiring the binding level to provide a > "callback" for migrationCreate (and any other future Vdsm->world requests). > This would complicate the beautiful png at > http://ovirt.org/wiki/Vdsm_API#Design ... Does anyone have another > suggestion? Actually, I think you are blending the external API with vdsm internals. As a management server or ovirt-engine, I don't care about the protocol that vdsm uses to contact the migration recipient. As far as I am concerned this is a special case internal function call. For that purpose, I think xmlrpc is perfectly well-suited to the task and should be used unconditionally, regardless of the bindings used to initiate the migration. So I would propose that we modify the design such that we keep an extremely thin xmlrpc server active whose sole purpose is to service internal P2P requests. -- Adam Litke <a...@us.ibm.com> IBM Linux Technology Center _______________________________________________ vdsm-devel mailing list email@example.com https://fedorahosted.org/mailman/listinfo/vdsm-devel