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