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