xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: libvir-list@redhat.com, xen-devel@lists.xensource.com
Subject: Re: [libvirt] [Xen-devel] [PATCH 5/5] Add a test suite for libxl option generator
Date: Mon, 2 Jun 2014 13:57:52 +0100	[thread overview]
Message-ID: <20140602125752.GI28039@redhat.com> (raw)
In-Reply-To: <1401713626.19553.5.camel@kazak.uk.xensource.com>

On Mon, Jun 02, 2014 at 01:53:46PM +0100, Ian Campbell wrote:
> 
> On Fri, 2014-05-30 at 18:24 +0100, Daniel P. Berrange wrote:
> > +    if (STRNEQ(expectargv, (char *)actualargv)) {
> > +        virtTestDifference(stderr, expectargv, (char *)actualargv);
> > +        goto cleanup;
> > +    }
> 
> Since you are using libxl_domain_config_gen_json you can control the
> pretty printing, but if you were to use the libxl_domain_config_to_json
> you might have problems if the library was to do something slightly
> different e.g. with whitespace.
> 
> In 4.5 we will have libxl_*_from_json and (I think) libxl_*_compare, so
> you could read in the template and compare it with the generated struct.
> That doesn't help you now of course.
> 
> Also in 4.5 the json will omit fields which are set to the their
> explicit default value. libxl_*_from_json will still do the right thing,
> but it'd be another annoyance for you here I think.
> 
> Lastly, when we add new fields to the API they will start showing up in
> the json (modulo the omission of defaults discussed above).

Hmm, that's a v good point.

> Other than having a template per libxl version (yuck) I don't have any
> particularly smart suggestions except for to aim long
> term for:
>   libxl_domain_config_init(..., &template)
>   libxl_domain_config_from_json(..., &template, "{ json json json ....")
> 
>   libxl_domain_config_init(..., &xml)
>   virtLibxlFromXML(..., &xml, "<domain>....")
> 
>   libxl_domain_config_compare(&template, &xml)
> 
> which will likely handle all of those corner cases, except perhaps the
> case where libvirt is using new fields on new versions of libxl etc. I
> suppose that would be handled by specific unit tests for >= and <
> versions of libxl separately?

I think that perhaps I should just add a general JSON "DOM" comparison
function in libvirt - no need for it to be libxl specific, as it might
be useful for libvirt JSON usage elsewhere.

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 :|

  reply	other threads:[~2014-06-02 12:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-30 17:24 [libvirt] [PATCH 0/5] Testing libvirt XML -> libxl_domain_config conversion Daniel P. Berrange
2014-05-30 17:24 ` [libvirt] [PATCH 1/5] Don't pass virDomainObjPtr to libxlBuildDomainConfig Daniel P. Berrange
2014-05-30 22:26   ` Jim Fehlig
2014-05-30 17:24 ` [libvirt] [PATCH 2/5] Don't pass libxlDriverPrivatePtr into libxlBuildDomainConfig Daniel P. Berrange
2014-05-30 22:34   ` Jim Fehlig
2014-05-30 17:24 ` [libvirt] [PATCH 3/5] libxl: Move virDomainXMLOptionNew into libxlCreateXMLConf Daniel P. Berrange
2014-05-30 22:41   ` Jim Fehlig
2014-06-02  9:33     ` Daniel P. Berrange
2014-05-30 17:24 ` [libvirt] [PATCH 4/5] Add more test suite mock helpers Daniel P. Berrange
2014-05-30 17:24 ` [PATCH 5/5] Add a test suite for libxl option generator Daniel P. Berrange
2014-06-02 12:53   ` Ian Campbell
2014-06-02 12:57     ` Daniel P. Berrange [this message]
2014-06-02 21:42       ` Jim Fehlig
2014-06-02 12:41 ` [PATCH 0/5] Testing libvirt XML -> libxl_domain_config conversion Ian Campbell
2014-06-02 12:49   ` [libvirt] [Xen-devel] " Daniel P. Berrange
2014-06-02 22:43     ` Jim Fehlig
2014-06-03  9:26       ` [libvirt] [Xen-devel] " Daniel P. Berrange
2014-06-02 12:57   ` Ian Campbell
2014-06-02 13:15     ` Processed: " xen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140602125752.GI28039@redhat.com \
    --to=berrange@redhat.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=libvir-list@redhat.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).