Re: [Libvir] RFC: get/set properties
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 :|