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.

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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to