On 04/09/2009 11:26 AM, Daniel P. Berrange wrote:
There should be XML parsing & formatting routines in libvirt because
not everything is going to use netcf, and the test driver shouldn't
depend on it. Even for drivers using netcf, libvirt will also have
to potentially augment info returned from netcf. For example, with
interfaces that are online, libvirt needs to include information
about the IPv4/6 addresses obtained by DHCP / IPv6 autoconfig, and
potentially more ops that are not related to configuration. Looking
at the VirtualBox API, I see it provides a full set of RPC APIs for
dealing with physical interface config, so that will need the XML
parsing APIs in libvirt too.
With all this new information (for me anyway ;-), I think we can all
agree that we will, in the end, need to be able to parse the interface
XML in libvirt, and should have a test driver that is fully functional
with no external dependencies (see Cole and Dan's previous mails). On
the other hand, there's a very short time until the release that we want
minimal netcf functionality in, and an impaired newbie is doing the work.
So, in the interest of getting the most useful stuff into the code in
the shortest time, here is a proposed schedule of what to do when. All
of these things will be done before the entire task is considered
complete, but some will be finished 2 releases from now rather than for
the next release. Each of the steps will be committable in their own
right, thus allowing maximum use before release:
1) implement a live interface driver that is simply a passthrough to
netcf, no parsing/formatting of XML, just a conduit. This will give us
something that can demonstrate the new functionality and be useful.
2) implement a test driver that uses netcf in "alternate root" mode
(with a flag during init to turn off the iptables tweaking and disable
if_up and if_down) (this may or may not be ready for the next release).
3) implement XML parsing/formatting functions for interfaces in libvirt.
(this is a functional no-op, so wouldn't necessarily need to be
committed until step (4), although at this point someone could use these
functions to implement a VirtualBox interface driver, for example).
4) modify the test driver to keep its own list of interfaces, and call
the parsing/formatting code in (3) rather than netcf.
5) modify the live driver from (1) to do the parse/format as XML is
going to/from netcf, and add-in things that netcf doesn't do (eg,
interface state, DHCP addresses, etc).
(we might want to switch the order of 4 and 5)
This is not nearly as nice as presenting the entire thing all at once in
one giant comprehensive set of patches, but makes it possible to get a
working (albeit not ideal) "configure physical host interfaces" feature
into the next libvirt release, and doesn't produce too much throwaway code.
Does this sound acceptable?
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list