Re: [libvirt] [PATCH v2 4/4] libxl: Add a test suite for libxl option generator

["Daniel P. Berrange" <berrange@redhat.com>]

On Tue, Jun 17, 2014 at 12:40:30PM -0600, Jim Fehlig wrote:
> Ian Campbell wrote:
> > On Mon, 2014-06-16 at 17:11 -0600, Jim Fehlig wrote:
> >   
> >>> This function exists in Xen 4.2 as well, in libxl.h.
> >>>   
> >>>       
> >> Any ideas on how to handle this?  I'm not aware of an existing macro to
> >> check for func 'foo' defined in header 'bar'.  Is writing a custom macro
> >> along these lines a good solution?  A bad solution I tried was hacking
> >> the test to check libxl version via libxl_get_version_info(), but that
> >> API does not work if not running Xen.
> >>     
> >
> > Given that it exists in everything from 4.2 onwards why do you need to
> > check for it?
> >   
> 
> Hrm, right.  I had the half-brained idea to use this to solve the
> failures I saw when testing this series against Xen 4.2
> 
> https://www.redhat.com/archives/libvir-list/2014-June/msg00170.html
> 
> I think the solution to that specific problem is to use Xen 4.2 config
> as the baseline.  But it got me thinking about the general problem you
> mentioned near the end of this mail
> 
> https://www.redhat.com/archives/libvir-list/2014-June/msg00032.html
> 
> With virJSONStringCompare in 1/1, Daniel provides a way to handle
> existence of new fields showing up in the json.  But what if I want to
> write a test where the expected data is not supported on earlier
> versions?   E.g. how would I add a test to check conversion of '<tpm
> ...>' to 'vtpms: [ ]' and expect that to work when running 'make check'
> against a 4.2 libxl where vtpms were not yet supported?  I suppose each
> such test would have to probe for the feature it checks and skip if not
> found.

My last approach was to allow the JSON comparator to skip certain
types of missing data but I don't think that's sufficiently flexible
anymore. I'm thinking instead, that we could maintain a set of
context paths which designate things that are new in each version,
which would indicate things that should be skipped with old versions.

So we with 4.3, we'd list

  /c_info/driver_domain
  /c_info/pvh

and any other newly added fields. Then when running the test on 4.2
if the expected XML contained either of those paths, we'd skip them
when comparing against the actual JSON.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|