Re: [libvirt] test driver for interface config
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