[Ovirt-devel] Managed Node qpid Modeling

[Daniel Veillard]

On Thu, Jul 10, 2008 at 10:18:56AM +0100, Daniel P. Berrange wrote:
> On Wed, Jul 09, 2008 at 09:55:44PM -0700, Ian Main wrote:
> > So please take a look and feel free to post questions or comments.
> > 
> >     <method name="create_domain" desc="Start a new domain">
> >       <arg name="description" dir="I" type="sstr" desc="Domain description"/>
> >       <arg name="vcpus" dir="I" type="unit32" desc="Number of virtual CPUs"/>
> >       <arg name="max_memory" dir="I" type="unit32" desc="Maximum memory allocated in KB"/>
> >       <arg name="current_memory" dir="I" type="unit32" desc="Memory to use in KB"/>
> >       <arg name="boot_device" dir="I" type="sstr" desc="Boot device"/>
> > 
> >       <arg name="domain" dir="O" type="sstr" desc="Newly created domain object"/>
> >       <arg name="result" dir="O" type="ObjID" desc="Description of result.  'success' or 'failure: error msg'"/>
> >     </method>
> 
> This is a seriously bad direction to take. libvirt explicitly uses XML for
> passing domain creation information so that it is extendable without having
> to constantly change the API of the creation methods. IMHO any wire protocol
> between managed nodes and WUI should map pretty much 1-to-1 onto the libvirt
> APIs. 

  Agree. And even if AMQP is usually used to transport SOAP payload, I don't
think you have to a priori restrict yourself to that format.

> In fact rather than defining an oVirt AMQP protocol I'd like this to be
> positioned as the canonical libvirt AMQP protocol.  This will enable good
> interoperability for any other applications using AMQP who also interact 
> with libvirt. For it to be a libvirt AMQP protocol it should be a pretty 
> much direct serialization of libvirt API onto the wire.

  Look at http://libvirt.org/html/libvirt-libvirt.html#virDomainCreateLinux
  virDomainPtr	virDomainCreateLinux	(virConnectPtr conn, 
  					 const char * xmlDesc,
					 unsigned int flags)

for the description of the creation API and
  http://libvirt.org/formatdomain.html
  http://libvirt.org/drvqemu.html#xmlconfig
for the description of the domain XML format used underneath.

  IMHO your suggested SOAP API encoding get immediately into the trap i tried
to avoid when designing libvirt API for creating a domain, which is that 
it's extremely hard to know the full set of informtations actually needed
to start a domain. Even with all the experience gained from Xen FV/PV, QEmu,
KVM, OpenVZ, LDom, etc. I would not be able to restrict that to a list. Even
if you were to put some abstraction by passing objects instead of basic types
you just can't block an API for something which is ultimately based on libvirt
the way you're suggesting.
  A trivial breakage is that as soon as someone adds support for Xen or LXC
to oVirt, the AMQP bindings will break beacause your boot methodology assumes
something like a boot device, but that's not necessarily the way those
hypervisor works.

  Maybe you don't want to revisit the case of using SOAP bindings on top
of AMQP, still you should try to stay in line with libvirt, a lot of work
and thoughts have been invested onto those APIs, please don't assume you
can build a different set, the divergence would kill the AMQP API in a
relatively short term.

> Sure you'll probably need some oVirt specific bits too for APIs outside the
> scope of libvirt, such as the broader monitoring  / stats stuff oVirt does.
> So we'll actually want 2 separate AMQP specifications - one for libvirt & 
> one for oVirt.

  Splitting the two might be a good option, yes.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/