[Libvir] [RFC] Life-cycle Management of the domain take2

[Daniel Veillard]

On Fri, Apr 27, 2007 at 07:57:09PM +0900, Saori Fukuta wrote:
> Hi,
> 
> I'm making a patch to provide a changing allocation dynamically and statically
> without keeping state at the library.
> And this is still uncompleted works, but I would like to hear your comments.

  I dislike the fact that we are making API confusing.
At the beginning, it was simple, a domain is a running instance, and 
API works on domain.
Then we started adding support for defined domains, with the premice that
a domain was either active or inactive, so the change in API semantic
was minimal.
Now you are proposing to override this with another layer of APIs which
allow a domain to be both the definition file somewhere, or the running
instance, or both or something next ...

  I'm saying, stop ! To me we are trying to push patches without keeping
the coehrency of the definitions 
   http://libvirt.org/intro.html

   "a domain is an instance of an operating system running on a
    virtualized machine provided by the hypervisor"

Maybe we need a different definition for what is a domain description, 
and then we can add APIs for those, but the confusion generated by the
drift of what a Domain may represent, starts now to impact the API and
I don't want that ! The goal is to keep the API simple, when you start
having APIs where an extra argument is added to change the primary
signification of what one of the argument means:
   - that means you have lost track of the objects exposed by the API
   - the API is becoming confusing

Now I understand you want a way to modify the Domain descriptions. This
should *NOT* use the virDomainPtr as the argument in the API. You need 
to define a different type of object, not overload the semantic of
similar API.

Define APIs with a different object virDomainDescription which could
be loaded from a file, a descriptor or memory, or grabbed from 
a running virDomain then defines similar API to modify them if needed.
But the fact that you can't get some informations like the VNC port
number from a running domain, while you could get it from a description
file is no excuse to start multiplying APIs. You're just trying to
use the wrong object for the job.

  I don't think the current patches you provided are in the right direction, 
I'm sorry I didn't manage to express my concern before more clearly but now
I think I know why I was resistant to your earlier suggestions. You are
trying to add functionalities in libvirt for object we don't have a good
representation for (descriptions of domains). But even if we want to do
similar kind of operation on those objects they are fundamentally of a
different type. And to address this cleanly we need to add support for
those type instead.

  This certainly deserve some discussions about how to define domain 
description types what kind of methods they would take, but the more I 
think about it the cleaner and easier it will be if we take that path
instead.

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/