Re: [KVM-AUTOTEST PATCH v2 3/6] [RFC] Introduce exception context strings
On 01/05/2011 06:21 PM, Avi Kivity wrote:
On 01/05/2011 06:12 PM, Avi Kivity wrote:
On 01/05/2011 05:45 PM, Michael Goldish wrote:
In complex tests (KVM) an exception string is often not informative
enough and
the traceback and source code have to be examined in order to figure
out what
caused the exception. Context strings are a way for tests to provide
information about what they're doing, so that when an exception is
raised, this
information will be embedded in the exception string. The result is
a concise
yet highly informative exception string, which should make it very
easy to
figure out where/when the exception was raised.
A typical example for a test where this may be useful is KVM's reboot
test.
Some exceptions can be raised either before or after the VM is
rebooted (e.g.
logging into the guest can fail) and whether they are raised before
or after
is critical to the understanding of the failure. Normally the
traceback would
have to be examined, but the proposed method makes it easy to know
where the
exception is raised without doing so. To achieve this, the reboot
test should
place calls to error.context() as follows:
error.context(before reboot)
carry out pre-reboot actions
error.context(sending reboot command)
send the reboot command
error.context(after reboot)
carry out post-reboot actions
If login fails in the pre-reboot section, the resulting exception
string can
can have something like context: before reboot embedded in it.
(The actual
embedding is done in the next patch in the series.)
It would be nice to make the error context a stack, and to use the
with statement to manage the stack:
with error.context(main test):
foo()
with error.context(before reboot):
bar()
If foo() throws an exception, the context would be main test, while
if bar() throws an exception, the context would be before reboot in
main test.
This seems like the best solution and it's unfortunate that we can't use it.
btw, you can have a decorator for enclosing an entire function in an
error context:
@function_error_context('migration test')
def migration_test(...):
...
anything in migration_test() is enclosed in that context. But we're
just repeating the ordinary stack trace with something more readable.
The problem is that the string passed to function_error_context can't be
based on function parameters, so declaring a context like 'migrating
vm1' is impossible.
I do think we can benefit from 2 context levels per function though:
@context_aware
def migrate(...):
base_context(migrating %s % vm.name)
context(collecting parameters)
...
context(sending monitor command)
...
context(cleanup)
...
base_context() and context() will just be joined together using ' -- '
like regular contexts. base_context() can be useful for long utility
functions. Does this sound like a reasonable solution, or do you think
it's cleaner to always define a new nested function for each context level?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KVM-AUTOTEST PATCH v2 3/6] [RFC] Introduce exception context strings
On Wed, Jan 05, 2011 at 05:45:26PM +0200, Michael Goldish wrote: In complex tests (KVM) an exception string is often not informative enough and the traceback and source code have to be examined in order to figure out what caused the exception. Context strings are a way for tests to provide information about what they're doing, so that when an exception is raised, this information will be embedded in the exception string. The result is a concise yet highly informative exception string, which should make it very easy to figure out where/when the exception was raised. A typical example for a test where this may be useful is KVM's reboot test. Some exceptions can be raised either before or after the VM is rebooted (e.g. logging into the guest can fail) and whether they are raised before or after is critical to the understanding of the failure. Normally the traceback would have to be examined, but the proposed method makes it easy to know where the exception is raised without doing so. To achieve this, the reboot test should place calls to error.context() as follows: error.context(before reboot) carry out pre-reboot actions error.context(sending reboot command) send the reboot command error.context(after reboot) carry out post-reboot actions If login fails in the pre-reboot section, the resulting exception string can can have something like context: before reboot embedded in it. (The actual embedding is done in the next patch in the series.) Signed-off-by: Michael Goldish mgold...@redhat.com Signed-off-by: Eduardo Habkost ehabk...@redhat.com --- client/common_lib/error.py | 97 +++- 1 files changed, 95 insertions(+), 2 deletions(-) Where's the automated test code? ;) +# def a(): +# error.context(hello) +# b() +# error.context(world) +# get_context() 'world' +# +# def b(): +# error.context(foo) +# c() +# +# def c(): +# error.context(bar) +# get_context() 'hello -- foo -- bar' The example above is outdated, isn't? It doesn't have the @context_aware decorator. -- Eduardo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KVM-AUTOTEST PATCH v2 3/6] [RFC] Introduce exception context strings
On 01/05/2011 05:45 PM, Michael Goldish wrote: In complex tests (KVM) an exception string is often not informative enough and the traceback and source code have to be examined in order to figure out what caused the exception. Context strings are a way for tests to provide information about what they're doing, so that when an exception is raised, this information will be embedded in the exception string. The result is a concise yet highly informative exception string, which should make it very easy to figure out where/when the exception was raised. A typical example for a test where this may be useful is KVM's reboot test. Some exceptions can be raised either before or after the VM is rebooted (e.g. logging into the guest can fail) and whether they are raised before or after is critical to the understanding of the failure. Normally the traceback would have to be examined, but the proposed method makes it easy to know where the exception is raised without doing so. To achieve this, the reboot test should place calls to error.context() as follows: error.context(before reboot) carry out pre-reboot actions error.context(sending reboot command) send the reboot command error.context(after reboot) carry out post-reboot actions If login fails in the pre-reboot section, the resulting exception string can can have something like context: before reboot embedded in it. (The actual embedding is done in the next patch in the series.) It would be nice to make the error context a stack, and to use the with statement to manage the stack: with error.context(main test): foo() with error.context(before reboot): bar() If foo() throws an exception, the context would be main test, while if bar() throws an exception, the context would be before reboot in main test. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KVM-AUTOTEST PATCH v2 3/6] [RFC] Introduce exception context strings
On Wed, Jan 05, 2011 at 06:12:05PM +0200, Avi Kivity wrote:
It would be nice to make the error context a stack, and to use the
with statement to manage the stack:
with error.context(main test):
foo()
with error.context(before reboot):
bar()
If foo() throws an exception, the context would be main test,
while if bar() throws an exception, the context would be before
reboot in main test.
Autotest targets Python 2.4, and Python 2.4 doesn't have the 'with'
statement.
The error context is already a stack, but without the 'with' statement
you would have to use try/finally explicitly:
_new_context('foo')
try:
# [...]
finally:
_pop_context()
By the way, I think we could make _new_context() and _pop_context() part
of the public interface (i.e. remove the _ from their names). I see
@context_aware as just a helper for a stack interface that could be used
directly if needed.
--
Eduardo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KVM-AUTOTEST PATCH v2 3/6] [RFC] Introduce exception context strings
On 01/05/2011 06:12 PM, Avi Kivity wrote:
On 01/05/2011 05:45 PM, Michael Goldish wrote:
In complex tests (KVM) an exception string is often not informative
enough and
the traceback and source code have to be examined in order to figure
out what
caused the exception. Context strings are a way for tests to provide
information about what they're doing, so that when an exception is
raised, this
information will be embedded in the exception string. The result is
a concise
yet highly informative exception string, which should make it very
easy to
figure out where/when the exception was raised.
A typical example for a test where this may be useful is KVM's reboot
test.
Some exceptions can be raised either before or after the VM is
rebooted (e.g.
logging into the guest can fail) and whether they are raised before
or after
is critical to the understanding of the failure. Normally the
traceback would
have to be examined, but the proposed method makes it easy to know
where the
exception is raised without doing so. To achieve this, the reboot
test should
place calls to error.context() as follows:
error.context(before reboot)
carry out pre-reboot actions
error.context(sending reboot command)
send the reboot command
error.context(after reboot)
carry out post-reboot actions
If login fails in the pre-reboot section, the resulting exception
string can
can have something like context: before reboot embedded in it.
(The actual
embedding is done in the next patch in the series.)
It would be nice to make the error context a stack, and to use the
with statement to manage the stack:
with error.context(main test):
foo()
with error.context(before reboot):
bar()
If foo() throws an exception, the context would be main test, while
if bar() throws an exception, the context would be before reboot in
main test.
btw, you can have a decorator for enclosing an entire function in an
error context:
@function_error_context('migration test')
def migration_test(...):
...
anything in migration_test() is enclosed in that context. But we're
just repeating the ordinary stack trace with something more readable.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KVM-AUTOTEST PATCH v2 3/6] [RFC] Introduce exception context strings
On 01/05/2011 06:21 PM, Eduardo Habkost wrote:
On Wed, Jan 05, 2011 at 06:12:05PM +0200, Avi Kivity wrote:
It would be nice to make the error context a stack, and to use the
with statement to manage the stack:
with error.context(main test):
foo()
with error.context(before reboot):
bar()
If foo() throws an exception, the context would be main test,
while if bar() throws an exception, the context would be before
reboot in main test.
Autotest targets Python 2.4, and Python 2.4 doesn't have the 'with'
statement.
Too bad :(
The error context is already a stack, but without the 'with' statement
you would have to use try/finally explicitly:
_new_context('foo')
try:
# [...]
finally:
_pop_context()
By the way, I think we could make _new_context() and _pop_context() part
of the public interface (i.e. remove the _ from their names). I see
@context_aware as just a helper for a stack interface that could be used
directly if needed.
Yeah.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KVM-AUTOTEST PATCH v2 3/6] [RFC] Introduce exception context strings
On Wed, Jan 05, 2011 at 06:21:35PM +0200, Avi Kivity wrote:
btw, you can have a decorator for enclosing an entire function in an
error context:
@function_error_context('migration test')
def migration_test(...):
...
@context_aware does that, but it doesn't let you set the context string
(it just initializes it to (function_name)). I think it is enough for
our purposes (and it keeps the API simple).
anything in migration_test() is enclosed in that context. But we're
just repeating the ordinary stack trace with something more
readable.
The context information is more useful for cases we want to know where
exactly we were, inside a single function (e.g. did we crash before or
after migration finished?). So the API is optimized for the cases where
we actually want to change the context string inside the same function.
--
Eduardo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KVM-AUTOTEST PATCH v2 3/6] [RFC] Introduce exception context strings
On 01/05/2011 06:36 PM, Eduardo Habkost wrote:
On Wed, Jan 05, 2011 at 06:21:35PM +0200, Avi Kivity wrote:
btw, you can have a decorator for enclosing an entire function in an
error context:
@function_error_context('migration test')
def migration_test(...):
...
@context_aware does that, but it doesn't let you set the context string
(it just initializes it to (function_name)). I think it is enough for
our purposes (and it keeps the API simple).
anything in migration_test() is enclosed in that context. But we're
just repeating the ordinary stack trace with something more
readable.
The context information is more useful for cases we want to know where
exactly we were, inside a single function (e.g. did we crash before or
after migration finished?). So the API is optimized for the cases where
we actually want to change the context string inside the same function.
Ok, makes sense. 'with' would have been nice, but I understand the need
for compatibility.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KVM-AUTOTEST PATCH v2 3/6] [RFC] Introduce exception context strings
On 01/05/2011 06:21 PM, Eduardo Habkost wrote:
On Wed, Jan 05, 2011 at 06:12:05PM +0200, Avi Kivity wrote:
It would be nice to make the error context a stack, and to use the
with statement to manage the stack:
with error.context(main test):
foo()
with error.context(before reboot):
bar()
If foo() throws an exception, the context would be main test,
while if bar() throws an exception, the context would be before
reboot in main test.
Autotest targets Python 2.4, and Python 2.4 doesn't have the 'with'
statement.
The error context is already a stack, but without the 'with' statement
you would have to use try/finally explicitly:
_new_context('foo')
try:
# [...]
finally:
_pop_context()
By the way, I think we could make _new_context() and _pop_context() part
of the public interface (i.e. remove the _ from their names). I see
@context_aware as just a helper for a stack interface that could be used
directly if needed.
To actually use the context you also have to insert it into an
exception, i.e.
_new_context('foo')
try:
try:
...
except Exception, e:
e._context = get_context()
finally:
_pop_context()
and I thought it would be more comfortable to just define a
@context_aware function and call it.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KVM-AUTOTEST PATCH v2 3/6] [RFC] Introduce exception context strings
On Wed, Jan 05, 2011 at 08:55:44PM +0200, Michael Goldish wrote:
On 01/05/2011 06:21 PM, Eduardo Habkost wrote:
By the way, I think we could make _new_context() and _pop_context() part
of the public interface (i.e. remove the _ from their names). I see
@context_aware as just a helper for a stack interface that could be used
directly if needed.
To actually use the context you also have to insert it into an
exception, i.e.
_new_context('foo')
try:
try:
...
except Exception, e:
e._context = get_context()
finally:
_pop_context()
True. Just forget about my suggestion. :)
--
Eduardo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
