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

Re: [libvirt] test driver for interface config



Daniel P. Berrange wrote:
> 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.
> 

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


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