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

[Saori Fukuta]

Hi Daniel

I'm sorry I might be disrespectful a little...
I understood descriptions of domains, and I will think over again with members 
of my team.

I appreciate your explaining.

    thanks a lot !

Saori

On Fri, 27 Apr 2007 07:47:51 -0400 Daniel Veillard wrote:
>   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/