Change hbal behaviour in case of early exit

Currently, hbal exits with status 1 if early exit is requested, even
when all jobs are successful. This is counter-intuitive behaviour, so
let's fix it (Issue 386).

Note that the man page had conflicting information already, so it's a
good thing to clean this up.

Signed-off-by: Iustin Pop <iustin@google.com>
Reviewed-by: Guido Trotter <ultrotter@google.com>

diff --git a/NEWS b/NEWS
index 2a09b2f..33488b5 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -87,6 +87,10 @@ Version 2.7.0 beta1
 - Instance renames of LVM-based instances will now update the LV tags
   (which can be used to recover the instance-to-LV mapping in case of
   emergencies)
 - Instance renames of LVM-based instances will now update the LV tags
   (which can be used to recover the instance-to-LV mapping in case of
   emergencies)

+- ``hbal`` will now exit with status 0 if, during job execution over
+  LUXI, early exit has been requested and all jobs are successful;
+  before, exit status 1 was used, which cannot be differentiated from
+  "job error" case

 
 
 Version 2.6.2
 
 
 Version 2.6.2

diff --git a/man/hbal.rst b/man/hbal.rst
index 701b551..766baac 100644 (file)
--- a/man/hbal.rst
+++ b/man/hbal.rst
@@ -400,16 +400,18 @@ in two ways:
 
 - by sending a ``SIGINT`` (``^C``), hbal will register the termination
   request, and will wait until the currently submitted jobs finish, at
 
 - by sending a ``SIGINT`` (``^C``), hbal will register the termination
   request, and will wait until the currently submitted jobs finish, at

-  which point it will exit (with exit code 1)
+  which point it will exit (with exit code 0 if all jobs finished
+  correctly, otherwise with exit code 1 as usual)
+

 - by sending a ``SIGTERM``, hbal will immediately exit (with exit code
 - by sending a ``SIGTERM``, hbal will immediately exit (with exit code

-  2); it is the responsibility of the user to follow up with Ganeti the
-  result of the currently-executing jobs
+  2\); it is the responsibility of the user to follow up with Ganeti
+  and check the result of the currently-executing jobs

 
 Note that in any situation, it's perfectly safe to kill hbal, either via
 the above signals or via any other signal (e.g. ``SIGQUIT``,
 ``SIGKILL``), since the jobs themselves are processed by Ganeti whereas
 hbal (after submission) only watches their progression. In this case,
 
 Note that in any situation, it's perfectly safe to kill hbal, either via
 the above signals or via any other signal (e.g. ``SIGQUIT``,
 ``SIGKILL``), since the jobs themselves are processed by Ganeti whereas
 hbal (after submission) only watches their progression. In this case,

-the use will again have to query Ganeti for job results.
+the user will have to query Ganeti for job results.

 
 EXIT STATUS
 -----------
 
 EXIT STATUS
 -----------

diff --git a/src/Ganeti/HTools/Program/Hbal.hs b/src/Ganeti/HTools/Program/Hbal.hs
index 26b1e3c..ece465f 100644 (file)
--- a/src/Ganeti/HTools/Program/Hbal.hs
+++ b/src/Ganeti/HTools/Program/Hbal.hs
@@ -186,8 +186,10 @@ execCancelWrapper _    _      _  _  _    [] = return $ Ok ()
 execCancelWrapper anno master nl il cref alljss = do
   cancel <- readIORef cref
   if cancel > 0
 execCancelWrapper anno master nl il cref alljss = do
   cancel <- readIORef cref
   if cancel > 0

-    then return . Bad $ "Exiting early due to user request, " ++
-                        show (length alljss) ++ " jobset(s) remaining."
+    then do
+      putStrLn $ "Exiting early due to user request, " ++
+               show (length alljss) ++ " jobset(s) remaining."
+      return $ Ok ()

     else execJobSet anno master nl il cref alljss
 
 -- | Execute an entire jobset.
     else execJobSet anno master nl il cref alljss
 
 -- | Execute an entire jobset.