1. 12 Nov, 2012 1 commit
    • Iustin Pop's avatar
      Change type of program options to 'IO [Options]' · d66aa238
      Iustin Pop authored
      Some options have defaults that depend on the environment, and we
      could handle these in two ways:
      - use a place-holder value (e.g. data X a = Default | Custom a) that
        is later read from the environment
      - move the options list to IO monad, where it can read the
        environment, etc.
      The second option allows also displaying the actual defaults in the
      `--help' output, even though it's not as nice, so I went with it.
      This patch only changes the option types, without actually changing
      any options yet.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarHelga Velroyen <helgav@google.com>
  2. 26 Oct, 2012 3 commits
    • Iustin Pop's avatar
      Convert Luxi results to Ganeti errors · 7adb7dff
      Iustin Pop authored
      This a bit too complex patch converts the result of Luxi calls
      (submitJob, query*, etc.) from Result to ErrorResult. It then
      immediately revers this in the HTools/Backend/Luxi module, where we
      don't need necessarily the full error type (just a nice error
      message), and does the same in Hbal's job execution functions.
      While at first sight this doesn't seem to do much, what we get is
      actual error messages from Ganeti, plus improvements to the result
      parsing: instead of "can't parse char", we now get properly (note,
      wrapped manually):
        Executing jobset for instances instance1, …
        Job submission error: Failure: the job queue is marked for drain and
          doesn't accept new requests
        Job submission error: Unhandled exception: LuxiError "parsing job
          id: cannot parse string 'a956101'"
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
    • Iustin Pop's avatar
      Move htools backends to a separate directory · 879d9290
      Iustin Pop authored
      Five modules under the HTools/ directories are backend
      implementations, so let's move them to a separate directory, to more
      clearly show the hierarchy. I wanted to do this for a while, but
      merging between branches is always an issue, so let's do it know since
      we have an opportunity.
      This patch contains the actual renames, the required changed module
      names, imports, etc., but no other changes.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
    • Iustin Pop's avatar
      Fix a few issues found by newer hlint · 66ad857a
      Iustin Pop authored
      Testing with a newer hlint found a few minor issues; but all are real,
      valid recommendations:
      - don't use "if cond then f x else f y", but "f (if cond then x else y)"
      - "if a then b else True" is equivalent to the simpler "not a || b"
      - and as usual, one more ignore to our "testing basic properties"
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
  3. 22 Oct, 2012 1 commit
  4. 18 Oct, 2012 1 commit
  5. 15 Oct, 2012 1 commit
    • Iustin Pop's avatar
      Cleanup HTools.Types/BasicTypes imports · 01e52493
      Iustin Pop authored
      Before we reorganised the source tree, the 'Result' type was exported
      from HTools/Types.hs. This changed during the reorg, but at that time
      we didn't change the exports; instead, we kept re-exporting it from
      the old module for compatibility.
      In light of future changes to the Result type, let's stop this
      re-export and cleanup the imports of the other modules.
      One test is slightly rewritten with explicit types declaration (part
      of the values already needed one, let's make it explicit).
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
  6. 08 Oct, 2012 2 commits
  7. 26 Sep, 2012 3 commits
  8. 18 Sep, 2012 1 commit
  9. 05 Sep, 2012 1 commit
    • Iustin Pop's avatar
      Further hlint fixes · 5b11f8db
      Iustin Pop authored
      Commit 2cdaf225, “Re-enable standard hlint warnings”, got it almost
      right. The only problem is that (confusingly) the default set of hints
      is not in HLint.Default, but in HLint.HLint (it includes Default and
      some built-ins).
      After changing the lint file to correctly include the defaults, we had
      another 128 suggestions:
        - Error: Eta reduce (2)
        - Error: Redundant bracket (4)
        - Error: Redundant do (17)
        - Error: Redundant lambda (7)
        - Error: Redundant return (1)
        - Warning: Avoid lambda (2)
        - Warning: Redundant $ (42)
        - Warning: Redundant bracket (35)
        - Warning: Use : (1)
        - Warning: Use String (4)
        - Warning: Use camelCase (10)
        - Warning: Use section (3)
      which are fixed by the current patch. Note that the 10 "Use camelCase"
      were all due to hlint not “knowing” the idiom of ‘case_’ (it does for
      ‘prop_’), for which I filled
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
  10. 28 Aug, 2012 1 commit
    • Iustin Pop's avatar
      Re-enable standard hlint warnings · 2cdaf225
      Iustin Pop authored
      Commit 5a1e31b4
       (Add infrastructure for, and two extra hlint rules)
      was intended to add two *extra* hlint rules, but I didn't realise at
      that time that "--hint" when first used overrides the built-in
      lints. As such, since then we were basically running with just those
      two rules, which resulted in many uncaught warnings/errors.
      This patch fixes that (by importing the standard lint rules in our
      custom hints file), and then goes to fix all the warnings that a
      current hlint gives me. Compared to our current style, we have just a
      few additions:
      - zipWithM instead of map foo . zip …
      - 'exitSuccess' instead of 'exitWith ExitSuccess'
      - more uses of '.'
      Additionally, we have to silence a case where hlint doesn't realise
      why we are using '\e -> const (return False (e :: IOError)' instead of
      just '\e -> return False' or even 'const (return False').
      One warning that is generated by hlint ("Use void") can't be fixed
      until we deprecate GHC 6.x, as only GHC 7 has the 'void' function in
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarAgata Murawska <agatamurawska@google.com>
  11. 07 Aug, 2012 1 commit
    • Iustin Pop's avatar
      Switch job IDs to numeric · 76b62028
      Iustin Pop authored
      This has been a long-standing cleanup item, which we've always
      refrained from doing due to the high estimated effort needed.
      In reality, it turned out that after some infrastructure improvements
      (the previous patches), the actual job queue-related changes are quite
      We will need to update the NEWS file later, but so far the RAPI
      documentation doesn't mention that the job ID is a string (it only
      says it is "a number"), so it doesn't look like it needs update.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
  12. 31 Jul, 2012 1 commit
  13. 05 Jul, 2012 1 commit
    • Iustin Pop's avatar
      hbal: return exit status 0 in case of early exit · 2a2e2610
      Iustin Pop authored
      This derives from an internal bug, but the story is consistent across
      both internal and external usage of hbal.
      Basically right now, hbal returns exit code 1 if requested to exit
      early, even if all jobs are successful. This is counter-intuitive due
      to two reasons:
      - hbal did what it was requested (exit early), so it shouldn't return error
      - there were no job failures, so there's nothing to "cleanup" or
        investigate on the Ganeti cluster, so again it shouldn't return
      Therefore the new behaviour is as follows:
      - for cases where all jobs were successful, even if terminated early
        via SIGINT or via --limit, we exit with code 0
      - for cases where jobs have failed or there were other errors in
        running hbal, the exit code is 1
      - for cases were hbal is requested an immediate termination (SIGTERM),
        exit code is 2, denoting "unknown whether the Ganeti cluster is
        consistent or not"
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
  14. 29 Jun, 2012 5 commits
  15. 28 Jun, 2012 3 commits
  16. 27 Jun, 2012 10 commits
  17. 25 Jun, 2012 4 commits