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

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


  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
  • From: "Graham, Simon" <Simon.Graham@xxxxxxxxxxx>
  • Date: Fri, 28 Jul 2006 13:33:12 -0400
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 28 Jul 2006 10:34:14 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcaxXsRFeH630Rf7TNWQiiX+wucQ7AAR9niQ
  • Thread-topic: [Xen-devel] [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@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser
> Sent: Thursday, July 27, 2006 5:26 AM
> To: Graham, Simon
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Attachment: xenstat-bug661.patch
Description: xenstat-bug661.patch

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

 


Rackspace

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