[Libvir] Proposal for the storage API (for discussion only)
Richard W.M. Jones
rjones at redhat.com
Mon Oct 22 07:49:34 UTC 2007
Daniel P. Berrange wrote:
> On Fri, Oct 19, 2007 at 01:35:25PM +0100, Richard W.M. Jones wrote:
>> I think this is fair enough. The important part is to make sure that
>> the sysadmin can configure it, and it doesn't make much difference
>> whether we use scriptlets or just have configuration options.
> It depends on the level of configuration. I don't want the sysadmin to be
> configuring command line args directly. For any input XML metadata to the
> libvirt API, we should always run a pre-determined command argv. This is
> important to ensure that the same storage description results in the same
> underlying operations no matter what machine it is run on. This ensures
> that applications have a consistent API, and that people debugging bug
> reports don't have to worry about local modifications to the API's meaning.
> The sysadmin can define the configure the storage pools they wish to have
> available via the APIs we provide directly.
> Now, if we want the sys-admin to be able to provide specific command line
> tools, for storage then I'd suggest we add an explicit 'site local' storage
> pool type. A 'site local' pool type would simple hand all the operations
> off to sysadmin configured commands.
> This way, if they use the built in lvm, or file, or iscsi, or block device
> backends we know exactly what the results are going to be. If they use the
> 'site local' backend we know to expect the unexpected.
Sure ... What I had in mind what that the sys admin should be able to
enable and disable different back-ends, but the actual command line
being used would be hidden within libvirt's C code.
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...
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
More information about the libvir-list