Xen devel - Jul 2006 - RE: [PATCH] Minor fix to xentop to stop it dying whendomains go away at the wrong time

Good suggestions - you are right that we only have issues when a VM is
in transition so simply removing it from the returned list should be
fine.

Turns out that this also means the collectors don''t need to return
special codes either - they are back to either working (and potentially
pruning a domain from the list) or failing completely.

Patch attached (boy, this is taking waaay more time than I expected!)

Simon
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Keir Fraser
> Sent: Thursday, July 27, 2006 5:26 AM
> To: Graham, Simon
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Minor fix to xentop to stop it dying
> whendomains go away at the wrong time
> 
> 
> On 26 Jul 2006, at 21:36, Graham, Simon wrote:
> 
> > OK - I''ve reworked the fix to put it in libxenstat -- still
not
> > completely convinced I like it, but take a look and let me know what
> > you
> > think - as you suggested, I''ve made the collectors return a
value
> > indicating if a fatal error occurred (-ve), a retryable error
> occurred
> > (0) or they were successful (+ve) and put in code to retry from the
> top
> > when a retryable error occurs (with a small 1/4s delay so we
don''t
> spin
> > wildly whilst things stabilize).
> 
> Thinking about this some more, those retryable failures will generally
> mean that a domain is being created or being destroyed. In those two
> cases, perhaps xenstat_get_node() should simply prune the problematic
> domain from the list it returns? That would avoid unbounded delay in
> xenstat_get_node().
> 
> I think what you have so far is okay: fatal error in a collector
causes
> error in the caller; recoverable error could cause domain to be pruned
> rather than retrying in the caller. Maybe we should have macros for
the
> possible return values from a collector: -1/0/+1 return values are not
> immediately obvious.
> 
>   -- Keir
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 28 Jul 2006, at 18:33, Graham, Simon wrote:
> Good suggestions - you are right that we only have issues when a VM is
> in transition so simply removing it from the returned list should be
> fine.
>
> Turns out that this also means the collectors don''t need to return
> special codes either - they are back to either working (and potentially
> pruning a domain from the list) or failing completely.
>
> Patch attached (boy, this is taking waaay more time than I expected!)
This looks good, but:
  1. Needs to be against xen-unstable (doesn''t apply right now, due to 
differences between unstable and testing trees)
  2. Please provide an up-to-date checkin comment and signed-off-by line.

Fix these two issues and I''ll check it straight in.

  Thanks,
  Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel