1. 06 Dec, 2012 1 commit
  2. 23 Nov, 2012 1 commit
  3. 15 Nov, 2012 2 commits
  4. 07 Nov, 2012 1 commit
    • Iustin Pop's avatar
      Switch devel/upload to a static file · f9435bdc
      Iustin Pop authored
      We had twice in the past days questions about devel/upload being
      "broken", since bash re-reads shell scripts during their run and this
      file can get regenerated due to Makefile changes.
      Since we only need this to be dynamically built for 3 variables, let's
      make the file static and read those three variables when it is run,
      instead of when it is built, which allows us to re-read the "latest
      version" of these vars as well.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
  5. 23 Oct, 2012 1 commit
  6. 16 Oct, 2012 1 commit
  7. 11 Oct, 2012 1 commit
  8. 08 Oct, 2012 1 commit
    • Iustin Pop's avatar
      Merge ganeti-master-cleaner back into ganeti-cleaner · 46118ed2
      Iustin Pop authored
      As I wrote during/after the review on commit 2958c56e, “ganeti-cleaner:
      Separate queue cleaning code”, while I appreciated the permission
      separation, I didn't like too much the file-based approach:
      - it is a very simple script, and lots of the code is duplicated
        between the two; I wouldn't like to see "ganeti-vmcapable-cleaner",
        "ganeti-master-candidate-cleaner", etc. in the future
      - ganeti-master-cleaner "pollutes" the namespace, creating
        tab-completion conflicts with ganeti-masterd
      This patch simply merges the master-cleaner back into cleaner, while
      keeping the separate user permissions scheme, separate log files, etc.
      Additionally, it fixes two bugs in the unit-test (not run with set -u
      and wrong path in the master-cleaner log files test; yay for even
      worse safety than Python?).
      And finally, since we have now support for --help-completion, it adds
      bash completion support for this script :) (needs to be applied on top
      of my argument suppo...
  9. 02 Oct, 2012 1 commit
  10. 28 Sep, 2012 1 commit
  11. 27 Sep, 2012 2 commits
  12. 19 Sep, 2012 1 commit
  13. 05 Sep, 2012 1 commit
  14. 04 Sep, 2012 3 commits
    • Iustin Pop's avatar
      Remove QC.hs and replace it with an auto-generated file · b88fcdd0
      Iustin Pop authored
      In order to have correct code coverage results, we must somehow import
      all production modules into the test runner. Until now, this was done
      manually (when we didn't forget) in QC.hs.
      To improve the situation, we remove QC.hs and replace it with an
      auto-generated file which imports all modules. This reduces the
      maintenance burden and ensures we'll always have correct coverage.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
    • Iustin Pop's avatar
      Move generated htools test stubs to htest/ · 189b51fa
      Iustin Pop authored
      This moves the last (I think) htools-related bits out of test/ under
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
    • Iustin Pop's avatar
      Move haskell test code to htest/ · f0f3a6df
      Iustin Pop authored
      This is the first commit of a series that will attempt to cleanup the
      test code organisation, which evolved somewhat organically from the
      initial pure htools functionality.
      The proposed organisation of the tree will be as follows:
      - htools (or maybe renamed to haskell or hs): only production code
      - htest: top-level test directory, containing test.hs, static helper
        scripts, etc.
      - htest/Ganeti/*.hs: modules implementing the actual test properties
        and test cases for the correspondingly-named production code modules
      - htest/data: containing test data files for the test cases
      This particular patch moves all the test code (test.hs, hpc-htools.hs
      symlink) and helper scripts (offline-test.sh, etc.) from htools/ to
      htest/, while updating the files themselves (if they had paths
      mentioning htools/), .gitignore and the Makefile.
      The only special mention is that in Makefile, we used to have a BINARY
      shell variable in binary build rule; that was computed via stripping
      `htools/' prefix; I've cleaned that and replaced with $(notdir $@);
      even though it's duplicated a few times, it leads to more readable
      make output (and easier to copy-paste).
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarAgata Murawska <agatamurawska@google.com>
  15. 23 Jul, 2012 1 commit
    • Iustin Pop's avatar
      Partial undo of "Makefile: Streamline directory creation" · 3735787e
      Iustin Pop authored
      Commit c964d962 changed the way we create directories, by two things:
      - unifying all dependencies and ad-hoc directory creation into a
        single target (all_dirfiles)
      - changing how directories are created from a stamp file to .dir files
        in each directory
      The first item is a very good one, but the second item is debatable:
      there's no per-se advantage of .dir files versus a single one,
      top-level, since both the .dir file and stamp-directories creation are
      depending on Makefile, which is the only one which can introduce new
      On the other hand, moving back from .dir files to stamp-directories
      has an advantage: "make -d | wc -l" does from ~8.7K lines to ~5.3K
      lines, because we eliminate the many .dir files and their multiple
      implicit and explicit dependencies (the %/.dir files fall under
      multiple patterns).
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
  16. 04 Jul, 2012 1 commit
  17. 19 Mar, 2012 1 commit
  18. 13 Mar, 2012 2 commits
  19. 22 Dec, 2011 2 commits
  20. 26 Oct, 2011 1 commit
  21. 26 Jul, 2011 1 commit
    • Iustin Pop's avatar
      Fix recompilation of htools on regen-vcs-version · 13aeae6a
      Iustin Pop authored
      Currently, most htools code depends on Constants.hs which is generated
      from constants.py and also depends on _autoconf.py. Also, _autoconf.py
      depends on vcs-version, which all together means that when 'make
      regen-vcs-version' is run, for example by ./devel/upload, most of the
      Haskell code needs recompilation.
      Since htools already has its 'optimised' vcs-version (and doesn't use
      the _autoconf.VCS_VERSION constants), we can optimise this as follows:
      - _autoconf.py doesn't contain the VCS_VERSION anymore, and that is
        instead moved to _vcsversion.py
      - constants.py depends on and imports this new module
      - _autoconf.py doesn't get regenerated at vcs-version changes, but
        only at re-running configure/changing Makefile time
      The end result is that only htools/Ganeti/HTools/Version.hs is
      recompiled now, which is a significant speedup (usually < 1 second
      versus 10 seconds previously).
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
  22. 19 Jul, 2011 5 commits
  23. 24 May, 2011 1 commit
    • Iustin Pop's avatar
      Implement conversion of Python constants to Haskell · d99d1e36
      Iustin Pop authored
      With the merge of the repositories, we can now auto-generate the code
      for Haskell constants from the Python code.
      Currently this only handles the basic types (strings and
      integers). Handling containers such as lists and dictionaries is only
      possible if we would use a parser such that we recognise the element
      names. We could extend the convert-constants script if that becomes
      necessary, right now I'm looking at just the simple constants such as
      Iallocator modes, instance states, etc.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
  24. 24 Mar, 2011 2 commits
  25. 23 Mar, 2011 1 commit
  26. 22 Mar, 2011 4 commits