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

Reply via email to