[Engine-devel] API design and plan

[Adam Litke]

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 <agl at us.ibm.com>
IBM Linux Technology Center