[Libvir] Proposal for the storage API (for discussion only)

[Richard W.M. Jones]

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 be
> a 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 known
> predictable 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20071019/563ee605/attachment-0001.bin>