On Wed, Feb 21, 2007 at 01:29:31PM +0000, Daniel P. Berrange wrote:
On Wed, Feb 21, 2007 at 11:54:13AM +0000, Mark McLoughlin wrote:
> On Sat, 2007-02-17 at 14:12 +0800, Daniel Veillard wrote:
>
> > Agreed let's not mix policies and data. However I assume the API would
allow
> > to define directories for autostarted configs. I guess having predefined dirs
for
> > such data is a common concept. And trying to hard code it like /etc/xen is
> > really not the best. IIRC we already have a config file now for some daemons,
> > can we have such directories entries in the config file ? I guess it would
give
> > the flexibility required for most uses while keeping a relatively sane API and
> > avoiding putting the policy in the data themselve.
>
> I don't think this is specific to the autostart support - i.e. we
> already define /etc/libvirt/qemu as the location for qemud domain
> definitions and don't have a configurable way of allowing other
> directories.
I think it is fine to hardcode at build time - simply allow use of a flag to
configure to change the default, or let the user override the default with a
flag to the libvirt_qemud process
>
> I've no objection to allowing multiple locations and making that
> configurable, but there is a few things to bear in mind:
I think allowing multiple directories is complete overkill and unnneccessarily
complicates the code, as you point out below... We're not really expecting
admins to manage these config files directly in any case, so I can't really
see any benefit to using many dirs.
I was thinking of case where we have unified daemons, and
where is may serve for example local QEmu virtualization but
also cluster like one where all data are expected to be on some
shared storage. Compile time only setting are IMHO not okay
in the long term, and I'm not even convinced that a single
directory will be sufficient either. I could perfectly see
how an user need one kind of network data, and that the cluster
softare being used on that box too needs completely different
data on a external storage. At least make it a runtime option
in some ways, or I'm just missing something :-)
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/