fix coredump-{restart, destroy} on_crash actions

After all of these years, more fallout from xen-api and legacy xmlrpc integration. Can't say I'll miss xend :-).

Please apply to xen-4.0-testing.

Regards,
Jim

# HG changeset patch
# User Jim Fehlig <[email protected]>
# Date 1280165174 21600
# Node ID 3da5c666fb1ba1f532803e59040e7a0d8481c2ba
# Parent ac7e4c6ec6c7494e4046da92aa8f62f6c1371438
The xm documentation and example config files state that possible "on crash" behaviors include coredump-{restart,destroy}, but domain creation will fail if either of these options are specified

xen52:~ # grep coredump /etc/xen/vm/test
on_crash="coredump-restart"
xen52:~ # xm create /etc/xen/vm/test
Using config file "/etc/xen/vm/test".
Error: Invalid argument.

coredump-and-{restart,destroy} are permissible but unnecessarily verbose and inconsistent with documentation. This patch simply adds coredump-{restart,destroy} to the list of permissible values.

diff -r ac7e4c6ec6c7 -r 3da5c666fb1b tools/python/xen/xend/XendAPIConstants.py
@@ -45,8 +45,10 @@
 XEN_API_ON_CRASH_BEHAVIOUR = [
     'destroy',
     'coredump_and_destroy',
+    'coredump_destroy',
     'restart',
     'coredump_and_restart',
+    'coredump_restart',
     'preserve',
     'rename_restart'
 ]

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

The path is via Ian Jackson or Stefano Stabellini into xenbits.xen.org/staging/xen-unstable-tools.hg, from there I pull into xen-unstable.hg. Then Ian or Stefano may nominate changesets from unstable to backport to 4.0-testing.

-- Keir

Jim Fehlig writes ("[Xen-devel] [PATCH] [xend] fix coredump-{restart, destroy} on_crash actions"):

We'll apply this to xen-unstable first, as Keir says. However, I'm not sure I fully understand how this patch works.

You're adding 'coredump_destroy' and 'coredump_restart' to the list of allowable settings, but you don't appear to provide a corresponding change to the implementation anywhere. How does this work ?

Ian.

Don't.

Well, I'm not surprised that you are confused. As it turns out, we have an internal patch that fixes a bug wrt 'xm create -x ...' not working - and that patch is causing the bug described here. Unfortunately it was never upstreamed, allowing such regressions to be spotted by others:-(.

Sorry for the noise.

Regards,
Jim