On Wed, Jul 02, 2014 at 10:32:59AM -0400, John Ferlan wrote:
> diff --git a/docs/formatdomaincaps.html.in
b/docs/formatdomaincaps.html.in
> new file mode 100644
> index 0000000..cfd61d9
> --- /dev/null
> +++ b/docs/formatdomaincaps.html.in
Since there's a "Capabilities" page describing the Driver (Host/Guest)
Capabilities and now this one for Domain - do you see a future need for
storage, network, etc. type capabilities? If so, other than the "volume
of data" then why not extend capabilities so that it could list
everything available for everything we know about? e.g.:
<capabilities>
<host... />
<guest... />
<domain... />
<storage... />
<network... />
<interface... />
</capabilities>
Architecturally, does it make sense to merge them or keep then separate?
There seems to be a relationship between them. Furthermore, if the goal
is to just provide information, then using one pile of xml output to
store everything may be useful to someone. For the more seasoned
individual using a specific/directed API that is planned will provide
the directed answer. I think the 'virsh capabilies' output certainly
shows it's possible to grab/use the various arch, machine, emulator, and
domain type values to generate lengthy output listing every possible option.
First we want the <capabilities> XML to keep a reasonable size. If we
listed everything in that one document, it would end up being many
many MB in size. Second, the capabilities XML can only provide info
on the default emulators known to libvirt. The separate API lets us
get info on non-default emulator binaries too.
To your original question though, I do see us adding more APIs in
the future to query info about storage & networking.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|