[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]