6:07 p.m.
On Tue, Dec 06, 2011 at 08:46:57AM -0600, Adam Litke wrote:
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.
Well, I can imagine we would like a host in distress to migrate VMs to
whomever can take them, without central management driving this process.
(CAVE split brain)
At the momemt I cannot think of something that cannot be implemented by
QMF events. Ayal?
> 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.
Interesting. We could avoid even that, if we could register a callback
with libvirt, so that destination libvirtd called destination Vdsm to
verify that all storage and networking resources are ready, before
executing qemu. DanPB, can something like that be done? (I guess it is
not realistic since we may need to pass vdsm-specific data from source
to dest, and libvirt is not supposed to be a general purpose transport.)
Dan.