On 04/10/2009 06:47 AM, Daniel P. Berrange wrote:
On Thu, Apr 09, 2009 at 02:21:20PM -0400, Laine Stump wrote:
> 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.
>
I'm afraid this isn't really going to fly. The libvirt public interface
is defined by C library API/ABI, and the XML format. To provide the
guarenteed stability & consistency of this interface across releases,
we need to have the XML parser & formatting included in libvirt & used
by all the driver impls.
Yes. I completely agree. I'm just saying that can't be done by the end
of next week (isn't that when the freeze for the next release will be?),
so how about we allow for something incremental that will get the motor
running, and in the following few weeks update it to make it "right".
(If not, then I'll do everything to completion before submitting any
patchsets, and it will necessarily be a later date before there's usable
functionality in the code)
We used to have the situation where XML parsing
was delegated to individual drivers, but that ultimately caused us
painful inconsistency between drivers.
Now in the case of the netcf impl for the interface APIs, things will
be nice & simple, because the incoming XML can be simply parsed & then
reformatted back into same schema.
And this is exactly why I think it would be acceptable, for a very short
time, to omit the parse/reformat - it is an identity transform. True, in
the long run it may not be, but long before the two schemas diverge, we
will be finished doing it the right way.
> 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).
>
I don't really see this as useful because it would have to be essentially
thrown away completely for the real impl of the test driver.
But it would be trivial to write - it would literally be the real driver
(already written at that point), with a different init call. And of
course, all the plumbing will stay, so it won't be 100% throwaway
> 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).
>
Step 3 really has to be the first step, and then step 5 won't be neccessary
at all, since it can be included right from the start.
Well, in your plan it *is* still necessary, it's just that it's an addon
to my step 1 ;-)