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 :|
next prev parent 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).