[Libvir] RFC: get/set properties

[Daniel P. Berrange]

On Tue, Apr 15, 2008 at 02:23:53PM -0700, Ryan Scott wrote:
> Daniel P. Berrange wrote:
> >On Tue, Apr 15, 2008 at 11:31:32AM -0700, Ryan Scott wrote:
> >>  I'd like to get some comments on the following...
> >>
> >>  We would like to use libvirt to store some properties related to a 
> >>domain.  This can be done by adding a simple get/set API as follows:
> >
> >What are the properties ?  I'm not really very enthusiastic about the
> >idea of adding API / XML for generic key,value properties. I think it
> >will quickly be abused as a way to add arbitrary, non-standardized 
> >hypervisor / driver specific configuration which would be better 
> >represented with explicit schema.
> 
> One thing we have in mind is driver/software version numbers.  For 
> example, the control tools may change the domain configuration based on 
> whether a certain driver has the support for a new feature.  If we 
> create the domain's xml with the driver information, we can make this 
> decision quickly, on the fly, in dom0.

What are the drivers for ? As an example, if you're refering to drivers
for the backend disk devices assigned to a guest, then we alreayd have
a  <driver/>  element for <disk> devices, where we can add a 'version='
attribute.

If its not per-domain specific, then we have the 'capabilities' XML 
format which can be used to expose information about the capabilities
of a hypervisor. For now we expose information about supported migration
protocols, supported OS types & architectures. There's clearly scope
for defining further bits of metadata here.

So unless more concrete examples of properties come to light I'm still
not seeing any compelling argument for generic key,value pairs.

> >One of the key ideas behind libvirt is that we try to provide a consistent
> >set of configuration options across all drivers. NB, I'm not saying we need
> >the lowest-common denominator - just that we try to formalize a way to
> >represent every configuration option in such a away that it could be 
> >applied
> >to any driver.  I don't think simple  key,value pairs are sufficient in the
> >general case. 
> 
> This wasn't meant to be a generic solution to handle storage of all 
> domain information.  For your example below, if someone wants more 
> information on the console, the API should be extended to allow that.
> 
> However, extending the API to every piece of information for a domain 
> seems to be overkill.  That's why we just want a simple name/value pair.

While extending the XML format for every piece of information is clearly
more work than a generic name/value pair, this is a worthwhile tradeoff
because it forces us to think about the scope of everything we add, and
hopefully come up with an optimal way of representing it. 

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|