1. 17 Apr, 2014 5 commits
  2. 27 Mar, 2014 1 commit
    • Petr Pudlak's avatar
      Make configuration per job/thread · f47b32a8
      Petr Pudlak authored
      Previously there was one shared configuration object for all jobs,
      threads and other tasks. This patch creates separate ConfigWrite
      instances for distinct jobs/threads.
      All exported methods of ConfigWriter are now wrapped in calls that
      obtain the ConfigLock from WConfD, read the current configuration, and
      optionally write it back to WConfD.
      _OpenConfig is now called at each such request (instead of just once at
      the creation time of ConfigWriter). A new method _CloseConfig is added
      that performs the necessary cleanup (saving the configuration, releasing
      the lock).
      _UpgradeConfig needs to be called every time a configuration is received
      from WConfd, to fix parts that aren't persisted by the Python code. This
      requires that it doesn't use any methods that acquire locks, and it must
      not save the configuration at the end (unless it's called just after
      creating a ConfigWriter instance in "offline" mode).
      The semantics of Update changes slightly. Before it just checked its
      argument existed in the configuration. Now it also checks that the
      its serial number is the same as in the master configuration state, to
      avoid overwriting changes in other threads. This will require fixing all
      calls to Update, in particular to avoid interspersing calls to Update
      and other ConfigWriter methods. In the future, we should aim to
      eliminate Update completely.
      All LUs now carry their own instance of ConfigWriter, with their
      corresponding job ID. Other cide that uses ConfigWriter identifies with
      job ID 'None' and thread ID.
      Signed-off-by: default avatarPetr Pudlak <pudlak@google.com>
      Reviewed-by: default avatarKlaus Aehlig <aehlig@google.com>
  3. 27 Feb, 2014 2 commits
  4. 20 Feb, 2014 1 commit
    • Hrvoje Ribicic's avatar
      Improve job status assert affected by race condition · e6e17529
      Hrvoje Ribicic authored
      In the sliver of time between choosing a waiting job to be executed and
      trying to acquire locks for its execution, the status of the job can be
      changed to canceling. An assert checking the job status neglected to
      take this into account, and raised an error that managed to perpetually
      lock the job in the canceling state. This patch resolves the issue by
      making the assert accept the canceling state as well, and exiting if
      the job was cancelled.
      Signed-off-by: default avatarHrvoje Ribicic <riba@google.com>
      Reviewed-by: default avatarKlaus Aehlig <aehlig@google.com>
  5. 20 Jan, 2014 1 commit
  6. 17 Dec, 2013 1 commit
  7. 05 Dec, 2013 1 commit
  8. 04 Dec, 2013 1 commit
  9. 08 Nov, 2013 2 commits
  10. 04 Oct, 2013 1 commit
    • Klaus Aehlig's avatar
      Provide means of submitting jobs to a drained queue · 346c3037
      Klaus Aehlig authored
      During an upgrade, the job queue needs to be drained in order to avoid
      new jobs coming to the cluster.  Nevertheless, the upgrade process
      needs to carry out some maintenance, like redistributing the new
      configuration, therefore, this patch provides a means of submitting
      jobs to a drained queue.
      Of course, once the more fine-grained job queue control will be implemented,
      this functionality can be removed.
      Signed-off-by: default avatarKlaus Aehlig <aehlig@google.com>
      Reviewed-by: default avatarJose Lopes <jabolopes@google.com>
  11. 07 Aug, 2013 1 commit
    • Jose A. Lopes's avatar
      Hook h2spy in Makefile.am · 580b1fdd
      Jose A. Lopes authored
      * add rules to Makefile.am to use hs2py to generate the Python opcodes
        from Haskell and update tests to check that Haskell and Python contain
        the same opcodes.
      * split 'opcodes.py' in 'opcodes.py.in_after' and 'opcodes_base.py',
        moving as much code as possible to 'opcodes_base.py' without
        creating a circular dependency
      * update reference in the remaining Python modules
      * remove lib/opcodes.py dependency from documentation target in order
        to prevent recompilation of documentation in the distributed source
        tarball, in particular because 'sphinx-build' is an optional
        dependency (issue 547)
      Signed-off-by: default avatarJose A. Lopes <jabolopes@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
  12. 22 Apr, 2013 1 commit
  13. 10 Apr, 2013 1 commit
  14. 13 Dec, 2012 1 commit
    • Michael Hanselmann's avatar
      jqueue: Improve inotify error reporting · 383477e9
      Michael Hanselmann authored
      This addresses issue 218. When the number of inotify watches is
      exhausted, for example by being set too low from the beginning or by
      other programs, waiting for a job to change would just report a lost job
      (e.g. “Error checking job status: Job with id 7817 lost”).
      This patch changes the job watcher to no longer catch
      “errors.InotifyError” and, this is by far the larger part of this patch,
      adds unittests for this situation.
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
  15. 11 Dec, 2012 1 commit
  16. 05 Dec, 2012 1 commit
  17. 20 Nov, 2012 1 commit
    • Iustin Pop's avatar
      Cleanup ht's use of positive/strictpositive · 2c9fa1ff
      Iustin Pop authored
      Currently, ht.py uses a bad terminology for positive/non-negative
      numbers. Per http://en.wikipedia.org/wiki/Positive_number
      , this is the
      correct terminology:
      - A number is positive if it is greater than zero.
      - A number is negative if it is less than zero.
      - A number is non-negative if it is greater than or equal to zero.
      - A number is non-positive if it is less than or equal to zero.
      So this patch renames things as follows:
      - TPositiveInt            ⇒ TNonNegativeInt
      - TStrictPositiveInt      ⇒ TPositiveInt
      - TMaybePositiveInt       ⇒ dropped, not used anywhere
      - TMaybeStrictPositiveInt ⇒ TMaybePositiveInt
      - TPositiveFloat          ⇒ TNonNegativeFloat
      - TStrictNegativeInt      ⇒ TNegativeInt
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
  18. 13 Nov, 2012 2 commits
  19. 08 Nov, 2012 1 commit
  20. 01 Nov, 2012 1 commit
  21. 25 Oct, 2012 3 commits
  22. 11 Oct, 2012 3 commits
  23. 05 Oct, 2012 2 commits
  24. 25 Sep, 2012 1 commit
  25. 18 Sep, 2012 1 commit
  26. 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>
  27. 15 Jun, 2012 1 commit
  28. 30 Mar, 2012 1 commit