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've no objection to allowing multiple locations and making that
configurable, but there is a few things to bear in mind:
- The common idiom for this is a stack of directories where
definitions in later dirs higher in the stack override definitions
in lower dirs
- When a definition is saved, should it be saved in the highest dir
in the stack, or where it was originally defined, or the later if
it's writable but fall back to the former?
- What about the mismatch between filenames and domain names?
1) Identical filenames with different domain names - if you have
domain Foo in /etc/libvirt/qemud/foo.xml and domain Bar in
/mydomains/foo.xml, should both domains be loaded or just the
highest foo.xml in the stack?
(If the former - think about saving. If e.g. you save Foo, it
may be saved to /mydomains/foo.xml, overwriting the definition
for Bar)
2) Identical domain names with different file names - if you have
domain Foo defined in /etc/libvirt/qemud/foo.xml and another
definition of domain Foo from /mydomains/bar.xml, should the
highest definition win?
Cheers,
Mark.