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

Re: [Xen-devel] [PATCH] [RFC] Fix RegEx Issues with xendomains for both SXP and JSON outputs of lx list -l

----- Original Message -----
> From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
> To: Ian Murray <murrayie@xxxxxxxxxxx>
> Cc: David Sutton <kantras@xxxxxxxxx>; George Dunlap 
> <george.dunlap@xxxxxxxxxxxxx>; Joshua Tuttle <jtuttle@xxxxxxxxx>; Ian Jackson 
> <Ian.Jackson@xxxxxxxxxxxxx>; "xen-devel@xxxxxxxxxxxxx" 
> <xen-devel@xxxxxxxxxxxxx>
> Sent: Wednesday, 26 June 2013, 11:50
> Subject: Re: [Xen-devel] [PATCH] [RFC] Fix RegEx Issues with xendomains for
 both SXP and JSON outputs of lx list -l
> On Tue, 2013-06-25 at 16:39 +0100, Ian Murray wrote:
>>  >________________________________
>>  > From: David Sutton <kantras@xxxxxxxxx>
>>  >To: Ian Murray <murrayie@xxxxxxxxxxx> 
>>  >Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxx>; George Dunlap 
> <george.dunlap@xxxxxxxxxxxxx>; Joshua Tuttle <jtuttle@xxxxxxxxx>; 
> Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>; 
> "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx> 
>>  >Sent: Tuesday, 25 June 2013, 16:14
>>  >Subject: Re: [Xen-devel] [PATCH] [RFC] Fix RegEx Issues with xendomains 
> for both SXP and JSON outputs of lx list -l
>>  > 
>>  >
>>  >
>>  >Reply below,
>>  >
>>  >
>>  >On Tue, Jun 25, 2013 at 9:55 AM, Ian Murray 
> <murrayie@xxxxxxxxxxx> wrote:
>>  >
>>  >
>>  >>Date: Sat, 22 Jun 2013 13:38:11 +0100
>>  >>Message-Id: 
> <1371904691-9842-1-git-send-email-murrayie@xxxxxxxxxxx>
>>  >>
>>  >>
>>  >>
>>  >>>>  As was suggested by David Sutton, there are probably more 
> issues with
>>  >>>>  this script than has been covered so far, but this change 
> makes
>>  >>>>  suspension and restoration work for me, at least. He 
> suggests there
>>  >>>>  are problems with zombies, etc.
>>  >>>
>>  >>> You mean the handling of zombies by this script, rather than 
> it somehow
>>  >>> causing zombies?
>>  >>
>>  >>Yes, handling of zombies.
>>  >>
>>  >>
>>  >>
>>  >Yes, it was handling of zombies - in particular the xendomains script
>>  was making use of the state information of the various domains, which
>>  isn't part of the information exported  by xl list -l in either format
>>  >
>>  I am guessing, but I would say the script used to use xl/xm list
>>  without the -l and thiis is where $state was set originally.
> That sounds like a good bet.
>>   As you point this isn't available from xl list -l (should it be?). If
>>  I was approaching this as a re-write, the first thing I would do would
>>  be to devise some test cases for all the things this script is
>>  supposed to deal with. I don't know how to create zombies at will, for
>>  example. Perhaps the hypervisor gurus do. Until that can be done, this
>>  script is going to be hard to test properly. Just my opinion.
> If you can create zombies then that is a bug I think, which we would fix
> and break your test case ;-)

I was thinking of...

xl zombify <domainid>     :)

> If I were going to write test cases for this script I would start by
> collecting a library of "xl list -l" outputs (both real world and
> handwritten) and devise a test mode which sucked this in instead of
> running the command and operated in a dry-run mode.
> This is effectively what we've done, to a greater or lesser extent
> (mostly lesser...), for xl disk stanza parsing
> (tools/libxl/check-xl-disk-parse) or pygrub (tools/pygrub/examples/).
> It's nice because when someone reports a bug you can just add their
> output to the set of things you test.

I think that is a good idea except it doesn't capture an issue if the output of 
the real xl list -l changes. Besides, I liked the idea of David S. to get away 
from parsing xl list -l. Assuming this is what happened, I am not sure of the 
design logic of changing the behaviour of xl list -l to work with JSON. IMHO, I 
would say better to add another option for that output, so as not to cause 
compatibility issues.

Anyway, one of the for future, I think.

> Ian.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.