Daniel P. Berrange wrote:
Using structures in the public API is not in keeping with the rest of the libvirt APIs. We should be using XML for the main metadata description of volumes & pools.
No, that doesn't make sense. XML for an API is a hack. It's hard to use it without requiring an additional external library to parse the XML. It's slow. It has the facade of maintaining ABI compatibility (because it's "just strings"), but in fact has no guaranteed ABI at all. It sits very poorly with static typing, virtually guaranteeing runtime errors that you are forced to do something about.
See previous discussion about capabilities, also a hack: https://www.redhat.com/archives/libvir-list/2007-March/msg00104.html Notice that all the structures in my proposal are versioned: >> struct virStorageGroup { >> int magic; /* Magic / structure version. */ >> char *name; /* Volume group name. */ >> int flags; /* Flags. */ >> unsigned long long size; /* Total size in kilobytes. */>> unsigned long long avail; /* Available (free) space in kilobytes. */
>> };and for structures which are passed in, the caller passes the structure size which allows both forwards and backwards compatibility:
* virStorageFileStat: * @conn: pointer to the hypervisor connection * @path: pathname of file * @statbuf: pointer to caller-allocated stat buffer (OUT) * @size: caller should set this to sizeof(*statbuf). <--- NB.
This is just one reason why I don't like the idea of simply running shell scripts in the back end. This will result in a unreliable, hard-to debug system. It may be a short term win on implementation speed, but it will bea PITA for long term maintainence. One thing you will immediately get is people writing scripts which add all kinda of custom crap to the XML destroying the benefit of libvirt which is the standardization. For any
I don't understand this. Scripts can be written which add custom fields to the XML, but since libvirt will just ignore those fields I don't see any issue.
given storage backend, we know what operations we need to be able to perform & so we have a finite set of commands we need to run with knownpredictable arguments. We just don't need the 'flexibility' of running arbitrary shell scripts & XML filters in the backend end.
We do because we need to be able to take the output of 'vgs', 'sfdisk', 'iscsiadm', etc., the output of each being essentially the same information (a list of volume groups plus the size and free space of each), and present that information in the same format back to libvirt. In this case a common format makes perfect sense. It need not be XML, it might be CSV, but in this case XML's extensibility makes sense, along with the fact that libvirt already parses XML.
(Note for people snoozing through this email, we're talking about two different uses of XML).
Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list