On Mon, Jun 22, 2009 at 10:58:49AM +0200, Jonas Eriksson wrote:
On Thu, Jun 18, 2009 at 05:14:44PM +0000 David Lutterkort wrote:
[..]
> There's a few more options we need to add for completeness, at least
> PERSISTENT_DHCLIENT, DHCPRELEASE, and DHCLIENT_IGNORE_GATEWAY are
> supported by initscripts.
This raises a question - how should the features of some backends
and the deficiencies of other backends be handled? Should netcf
aim to handle just about everything? What about libvirt in the
case that the netcf XML API is extended and the libvirt XML API
is incompatible? What about features that are very similar but
not exactly the same (an example is the SuSE STARTMODE which
allows an interface to be started automatically at boot, when the
if is hotplugged, from ifplugd (!= hotplugged, apparently), or
autostarted but never automatically shut down)?
libvirt does not require that all functionality is present on
all platforms. So as long as an error is raised if the user
requests an unsupported configuration, we're fine. As for the
XML question, libvirt requires 100% backwards compatability so
its XML format is essentially "append" only, existing features
cannot be dropped/changed. libvirt will be parsing & reformatting
all XML coming to/from netcf to guarentee that it is compliant
with libvirt's advertised schema (even if this happens to be the
same as netcf's)
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://ovirt.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|