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.

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.

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

vdsm-devel mailing list

Reply via email to