[libvirt] test driver for interface config
I'm now trying to write the test driver for the interface config driver that I'm putting into libvirt. For comparison I'm using the network driver. My understanding so far is that it calls the functions in the real driver to construct network objects and manipulate them, then just doesn't call the code that makes the changes to the system config. My driver is a bit different, in that I don't need any object management - I just pass everything through to the netcf library, and return the results to the caller; libvirt is just being used as an RPC conduit with some minimal wrapping. What I'm wondering now is exactly what the test driver should be testing - should the test driver also call netcf and return the results, or should it be a minimal interface driver in its own right that, for example, comes up with no interfaces, and allows adding only one? The former (call netcf) is problematic in that many netcf functions make changes to the real live network config (which I don't think is a very nice thing to have in test code, but maybe I'm being over-cautious) and netcf doesn't have provisions for a test mode where changes made to the config aren't committed. In the latter case it seems that not a lot will be tested (just the client side API, and libvirt's RPC - all parameter checking and XML parsing will be done by netcf), although maybe that's all anyone is looking for. I would hesitate to make the driver any more complicated than just allowing a single interface, or do any parameter validation that's normally done by netcf, since then much of the testing would be of code that was only used in the test itself - not very productive. Any advice?
Laine Stump wrote:
I'm now trying to write the test driver for the interface config driver that I'm putting into libvirt. For comparison I'm using the network driver. My understanding so far is that it calls the functions in the real driver to construct network objects and manipulate them, then just doesn't call the code that makes the changes to the system config.
My driver is a bit different, in that I don't need any object management - I just pass everything through to the netcf library, and return the results to the caller; libvirt is just being used as an RPC conduit with some minimal wrapping.
What I'm wondering now is exactly what the test driver should be testing - should the test driver also call netcf and return the results, or should it be a minimal interface driver in its own right that, for example, comes up with no interfaces, and allows adding only one?
The former (call netcf) is problematic in that many netcf functions make changes to the real live network config (which I don't think is a very nice thing to have in test code, but maybe I'm being over-cautious) and netcf doesn't have provisions for a test mode where changes made to the config aren't committed.
The test driver shouldn't do anything that will affect actual host configuration. So unless netcf can be put into some sort of 'test mode', calling out to it is probably a no go.
In the latter case it seems that not a lot will be tested (just the client side API, and libvirt's RPC - all parameter checking and XML parsing will be done by netcf), although maybe that's all anyone is looking for. I would hesitate to make the driver any more complicated than just allowing a single interface, or do any parameter validation that's normally done by netcf, since then much of the testing would be of code that was only used in the test itself - not very productive.
The two important pieces that the domain/network/storage test drivers provide are: - Lifecycle emulation (start, stop, define, undefine, etc.) - XML Validation Unfortunately the two are tied together, since for example a virDomain object contains info parsed from the XML. I think in this case it may be useful to provide a minimal XML parser for Define/Undefine operations. Looking at the proposed virInterface object, it looks like you would only need to pull out interface name and mac address. You could then just store the 'defined' XML doc to use for a call to dumpxml. This would enable implementing all the lifecycle and lookup* functions. Maybe you could also try to use the netcf rng file to further validate the 'defined' xml, but maybe that's too hacky to do from within the driver. That said, I haven't looked at the proposed libvirt API or netcf all that much, so the above could be unrealistic. As an example of how the driver will likely be used, think of supporting the interface APIs in virt-manager. As a developer, it would be nice to use the test driver to ensure that all the UI updating as interfaces go up and down, appear and disappear, etc. is in working order, and that the XML we are building at least isn't completely bogus. Mopping up those simple issues with the test driver will ideally make the live functional testing less painful, and help isolate bugs in the app vs. bugs in the library. Thanks, Cole
On 04/07/2009 11:16 AM, Cole Robinson wrote:
As an example of how the driver will likely be used, think of supporting the interface APIs in virt-manager. As a developer, it would be nice to use the test driver to ensure that all the UI updating as interfaces go up and down, appear and disappear, etc. is in working order, and that the XML we are building at least isn't completely bogus. Mopping up those simple issues with the test driver will ideally make the live functional testing less painful, and help isolate bugs in the app vs. bugs in the library.
Thanks, I hadn't considered that end of testing. It definitely sounds useful. I guess I need to make something more general purpose. A netcf test mode might help, but it may not be useful enough - for example it wouldn't work if the test client was one that didn't support netcf - when connecting to a test driver, it's always on the local machine, correct?
On Tue, Apr 07, 2009 at 11:41:39AM -0400, Laine Stump wrote:
On 04/07/2009 11:16 AM, Cole Robinson wrote:
As an example of how the driver will likely be used, think of supporting the interface APIs in virt-manager. As a developer, it would be nice to use the test driver to ensure that all the UI updating as interfaces go up and down, appear and disappear, etc. is in working order, and that the XML we are building at least isn't completely bogus. Mopping up those simple issues with the test driver will ideally make the live functional testing less painful, and help isolate bugs in the app vs. bugs in the library.
Thanks, I hadn't considered that end of testing. It definitely sounds useful. I guess I need to make something more general purpose.
A netcf test mode might help, but it may not be useful enough - for example it wouldn't work if the test client was one that didn't support netcf - when connecting to a test driver, it's always on the local machine, correct?
The test impl needs to be within libvirt so it is always available no matter whether netcf is available for the build, so it shouldn't use netcf at all. 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 :|
On Tue, 2009-04-07 at 16:50 +0100, Daniel P. Berrange wrote:
The test impl needs to be within libvirt so it is always available no matter whether netcf is available for the build, so it shouldn't use netcf at all.
For the time being though, netcf not being available also means that the virInterface calls won't do anything with any other driver, since there is no other driver impl. It makes more sense to me to use netcf during testing until there is a different implementation of the virInterface API - at that point that impl and the test driver will also be able to share a lot of code, so that we don't have lots of test-only code. David
On Tue, Apr 07, 2009 at 07:01:14PM +0000, David Lutterkort wrote:
On Tue, 2009-04-07 at 16:50 +0100, Daniel P. Berrange wrote:
The test impl needs to be within libvirt so it is always available no matter whether netcf is available for the build, so it shouldn't use netcf at all.
For the time being though, netcf not being available also means that the virInterface calls won't do anything with any other driver, since there is no other driver impl.
It makes more sense to me to use netcf during testing until there is a different implementation of the virInterface API - at that point that impl and the test driver will also be able to share a lot of code, so that we don't have lots of test-only code.
We certainly need a way to test netcf & the driver using it, but that's not what the 'test' driver in libvirt is for. It is solely for unit testing of libvirt driver internals, remote client, remote daemon and virsh, and end user applications. The test driver is intended to be entirely self contained, providing 'in-memory' implementations of the core API logic, and as such using netcf in any of this is not appropriate Functional testing of the netcf based driver is something that will be done separate from the test driver 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 :|
On Tue, Apr 07, 2009 at 10:39:22AM -0400, Laine Stump wrote:
I'm now trying to write the test driver for the interface config driver that I'm putting into libvirt. For comparison I'm using the network driver. My understanding so far is that it calls the functions in the real driver to construct network objects and manipulate them, then just doesn't call the code that makes the changes to the system config.
No, this isn't quite right. The test driver is a driver in its own right - it doesn't call into any of the 'real' network driver. Both the 'test' and 'real' network drivers share the same XML parsing & formatting routines and internal object structures from network_conf.h/.c
My driver is a bit different, in that I don't need any object management - I just pass everything through to the netcf library, and return the results to the caller; libvirt is just being used as an RPC conduit with some minimal wrapping.
It shouldn't really be any different - the same general pattern should work - interface_conf.{c,h} - generic XML parsing and formatting APIs - netcf_driver.c - the reusable netcf interface driver impl - test.c - the complete test driver impl - vmware_driver.c - the complete vmware driver impl So, the netcf_driver.c would provide impl of the interface APIs for any driver which doesn't provide an impl itself. eg QEMU, Xen. Other drivers like 'test' implement the full set of APIs directly themselves. I also expect any VMWare, Hyper-V, Xen-API driver to implement the interface APIs directly. All drivers would use the generic XML parsing/formatting APIs to construct an in-memory representation of the objects being managed. Even though its doing a passthrough to netcf library, the netcf driver would still need to parse the XML in accordance with libvirt defined schema. It just happens that netcf uses the same XML format, so it can then convert it back into XML and pass it on through to netcf.
What I'm wondering now is exactly what the test driver should be testing - should the test driver also call netcf and return the results, or should it be a minimal interface driver in its own right that, for example, comes up with no interfaces, and allows adding only one?
The test driver wouldn't call anything in netcf. It is intended to be an entirely self-contained in-memory impl of the APIs with all the semantics required by the public APIs.
The former (call netcf) is problematic in that many netcf functions make changes to the real live network config (which I don't think is a very nice thing to have in test code, but maybe I'm being over-cautious) and netcf doesn't have provisions for a test mode where changes made to the config aren't committed.
This is exactly why netcf would not be called from the test driver :-)
In the latter case it seems that not a lot will be tested (just the client side API, and libvirt's RPC - all parameter checking and XML parsing will be done by netcf), although maybe that's all anyone is looking for. I would hesitate to make the driver any more complicated than just allowing a single interface, or do any parameter validation that's normally done by netcf, since then much of the testing would be of code that was only used in the test itself - not very productive.
The test driver is designed to provide a way to do various unit test tasks - libvirt unit testing of the internal driver API framework - libvirt unit testing of the remote driver - libvirt unit testing of the libvirtd daemon - libvirt unit testing of the virsh program - Unit testing of end-user applications (eg virt-manager) Ultimately the test driver exposes as much functionality of the APIs as is possible, so that applications using it can exercise as much of their functionality as possible. So it'd certainly need to support multiple interfaces (with all the various configs - briding, bonding, vlans, etc) Regards, 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 :|
On 04/07/2009 11:35 AM, Daniel P. Berrange wrote:
On Tue, Apr 07, 2009 at 10:39:22AM -0400, Laine Stump wrote:
I'm now trying to write the test driver for the interface config driver that I'm putting into libvirt. For comparison I'm using the network driver. My understanding so far is that it calls the functions in the real driver to construct network objects and manipulate them, then just doesn't call the code that makes the changes to the system config.
No, this isn't quite right. The test driver is a driver in its own right - it doesn't call into any of the 'real' network driver.
Both the 'test' and 'real' network drivers share the same XML parsing & formatting routines and internal object structures from network_conf.h/.c
Right, that's what I meant, but it didn't come out that way - the corresponding functions in each driver are almost identical to each other, just with some crucial omissions in the test driver case. It's sounding like the test driver will be a larger, more complex beast than the live driver that has netcf behind it.
Even though its doing a passthrough to netcf library, the netcf driver would still need to parse the XML in accordance with libvirt defined schema. It just happens that netcf uses the same XML format, so it can then convert it back into XML and pass it on through to netcf.
I've heard differing opinions on that. As long as the format is identical, it's not really needed (as long as you can rely on proper error handling/reporting from netcf), but if it has to be done anyway for the test driver, then it's not much extra effort to do it for netcf too.
On Tue, 2009-04-07 at 16:35 +0100, Daniel P. Berrange wrote:
Even though its doing a passthrough to netcf library, the netcf driver would still need to parse the XML in accordance with libvirt defined schema. It just happens that netcf uses the same XML format, so it can then convert it back into XML and pass it on through to netcf.
While that is still the case (libvirt interafce XML == netcf XML), it makes more sense to exercise as much of netcf as possible in the tests. The 'root' argument to ncf_init makes that possible, and if there are other things needed, we should add it to netcf, and exercise as many as the same code paths as non-test uses will as possible.
The test driver wouldn't call anything in netcf. It is intended to be an entirely self-contained in-memory impl of the APIs with all the semantics required by the public APIs.
Given that the libvirt API is just pass-through for now, that would test much less of the 'live' code than we can and should exercise. David
On Tue, Apr 07, 2009 at 06:56:57PM +0000, David Lutterkort wrote:
On Tue, 2009-04-07 at 16:35 +0100, Daniel P. Berrange wrote:
Even though its doing a passthrough to netcf library, the netcf driver would still need to parse the XML in accordance with libvirt defined schema. It just happens that netcf uses the same XML format, so it can then convert it back into XML and pass it on through to netcf.
While that is still the case (libvirt interafce XML == netcf XML), it makes more sense to exercise as much of netcf as possible in the tests. The 'root' argument to ncf_init makes that possible, and if there are other things needed, we should add it to netcf, and exercise as many as the same code paths as non-test uses will as possible.
The test driver wouldn't call anything in netcf. It is intended to be an entirely self-contained in-memory impl of the APIs with all the semantics required by the public APIs.
Given that the libvirt API is just pass-through for now, that would test much less of the 'live' code than we can and should exercise.
The whole point of the test driver is explicitly to *not* test the 'live' code. We certainly do need to test the live netcf driver, but this is a separate thing from the 'test' driver impl of the virInterface APis. Regards, 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 :|
Daniel P. Berrange wrote:
On Tue, Apr 07, 2009 at 06:56:57PM +0000, David Lutterkort wrote:
Even though its doing a passthrough to netcf library, the netcf driver would still need to parse the XML in accordance with libvirt defined schema. It just happens that netcf uses the same XML format, so it can then convert it back into XML and pass it on through to netcf. While that is still the case (libvirt interafce XML == netcf XML), it makes more sense to exercise as much of netcf as possible in the tests. The 'root' argument to ncf_init makes that possible, and if there are other things needed, we should add it to netcf, and exercise as many as
On Tue, 2009-04-07 at 16:35 +0100, Daniel P. Berrange wrote: the same code paths as non-test uses will as possible.
The test driver wouldn't call anything in netcf. It is intended to be an entirely self-contained in-memory impl of the APIs with all the semantics required by the public APIs. Given that the libvirt API is just pass-through for now, that would test much less of the 'live' code than we can and should exercise.
The whole point of the test driver is explicitly to *not* test the 'live' code. We certainly do need to test the live netcf driver, but this is a separate thing from the 'test' driver impl of the virInterface APis.
I suppose it depends on the definition of 'live' here, since currently with the test driver we do go through the same XML parsing routines that the 'live' drivers use (that's how I interpreted David's intentions anyways). Obviously we don't want to be mucking with actual network interfaces, but if we can use netcf to parse XML, that saves code duplication, and tests relevant 'live' code. Just for my own clarification, is the interface driver _actually_ going to duplicate the XML parsing/building of netcf? I assumed we were just going to do a wholesale passthrough to netcf in that case. That sounds like the best thing to do to just get this up and running. If we need to in the future, we could always just fork off our own subset of the netcf format and implement our own parser. But it doesn't sound like it gains us much doing it up front. If we do rely on netcf for xml parsing, I think it would also be a reasonable requirement that netcf be installed to use the test driver interface commands. - Cole
On Thu, Apr 09, 2009 at 11:11:07AM -0400, Cole Robinson wrote:
I suppose it depends on the definition of 'live' here, since currently with the test driver we do go through the same XML parsing routines that the 'live' drivers use (that's how I interpreted David's intentions anyways). Obviously we don't want to be mucking with actual network interfaces, but if we can use netcf to parse XML, that saves code duplication, and tests relevant 'live' code.
Just for my own clarification, is the interface driver _actually_ going to duplicate the XML parsing/building of netcf? I assumed we were just going to do a wholesale passthrough to netcf in that case. That sounds like the best thing to do to just get this up and running. If we need to in the future, we could always just fork off our own subset of the netcf format and implement our own parser. But it doesn't sound like it gains us much doing it up front.
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. 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 :|
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?
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. 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.
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.
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. Regards, 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 :|
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 ;-)
On Sat, Apr 11, 2009 at 12:37:51AM -0400, Laine Stump wrote:
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?),
I don't see any compelling reason why we absolutely must have this ready for next release. I prefer to wait until the code is more developed than rushing to meet an unneccessary artificial date. I know this is listed as a Fedora 12 feature, but there's many months yet before feature freeze for that release, so plenty of dev time yet. Regards, 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 :|
On Tue, Apr 14, 2009 at 08:42:06AM +0100, Daniel P. Berrange wrote:
On Sat, Apr 11, 2009 at 12:37:51AM -0400, Laine Stump wrote:
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?),
I don't see any compelling reason why we absolutely must have this ready for next release. I prefer to wait until the code is more developed than rushing to meet an unneccessary artificial date. I know this is listed as a Fedora 12 feature, but there's many months yet before feature freeze for that release, so plenty of dev time yet.
David Lutterkort also doesn't feel netcf is ready to just drop into RHEL 5.4 since it has had near 0 testing... and the network management API isn't much good without netcf. So we need to keep pushing ahead to get this ready for rhel 6 but I don't see a whole lot of point in trying to rush it into 5.4. --Hugh
On 04/14/2009 10:42 AM, Hugh O. Brock wrote:
I don't see any compelling reason why we absolutely must have this ready for next release. I prefer to wait until the code is more developed than rushing to meet an unneccessary artificial date. I know this is listed as a Fedora 12 feature, but there's many months yet before feature freeze for that release, so plenty of dev time yet.
David Lutterkort also doesn't feel netcf is ready to just drop into RHEL 5.4 since it has had near 0 testing... and the network management API isn't much good without netcf. So we need to keep pushing ahead to get this ready for rhel 6 but I don't see a whole lot of point in trying to rush it into 5.4.
So everyone will rest easy - understood, acknowledged, and agreed. I had gotten the idea from somewhere that it was more urgent than it is. I am proceeding with the approved "by the book" method; right now working on the XML parsing.
On Fri, 2009-04-10 at 11:47 +0100, Daniel P. Berrange wrote:
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. We used to have the situation where XML parsing was delegated to individual drivers, but that ultimately caused us painful inconsistency between drivers.
Here though you're going excactly in the opposite direction: you will have two different validators that are in danger of diverging, when you could have just one.
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.
You don't even need to reformat - just pass the original string on. David
On Tue, 2009-04-07 at 10:39 -0400, Laine Stump wrote:
The former (call netcf) is problematic in that many netcf functions make changes to the real live network config (which I don't think is a very nice thing to have in test code, but maybe I'm being over-cautious) and netcf doesn't have provisions for a test mode where changes made to the config aren't committed.
The ncf_init call takes a 'root' argument which determines what netcf considers the fs root ('/' by default) It won't ever touch files outside of that root, i.e. you can use that to set up a sandbox. There's one smallwrinkle in that it will run iptables unconditionally (which fails if you don't run your tests as root) - but I could change the code to not do that. David
participants (5)
-
Cole Robinson -
Daniel P. Berrange -
David Lutterkort -
Hugh O. Brock -
Laine Stump