1. 08 Apr, 2010 2 commits
    • Iustin Pop's avatar
      ConfdClient: add synchronous wait for replies mode · bfbbc223
      Iustin Pop authored
      Currently, there is no way for a user of the confd client library to
      know how many replies there should be, whether all have been received,
      etc. This is bad since we can't reliably detect the consistency of the
      This patch attempts to fix this by adding a synchronous WaitForReply
      function that will wait until either a timeout expires, or until a
      minimum number of replies have been received (interested users should
      add similar functionality for the async case). The callback
      functionality will still do call-backs into the user-provided code
      during the wait, but after this function has returned, we know that we
      received all possible replies.
      Note: To account for the interval between initial send of the request,
      and calling of this function, we modify the expiration time of the
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
    • Iustin Pop's avatar
      ConfdClient: unify some internal variables · 71e114da
      Iustin Pop authored
      Currently the requests are tracked in _request and in _expire_requests.
      This is conventient, but it restricts the ability to extend the request
      tracking, e.g. via packet stats and/or extension of expiration time.
      This patch introduces a new simple class _Request that holds all
      properties of pending requests; it then uses instances of this class as
      values in _request instead of tuples, and removes the _expire_requests.
      The only drawback is the change in behaviour of _ExpireRequests:
      previously, it used to scan the list only up to the first non-expired
      request, after which it aborted. Now it will scan the entire dict, which
      (depending on workload) could change the time behaviour. I don't think
      this is a problem, as:
      - deleting from the head of a list is very expensive (list.pop(0);
        list.append() is an order of magnitude more expensive than deleting
        an element from a dictionary and re-adding it)
      - we should have more than tens or hundreds of pending requests; in case
        this assumption changes, we could introduce a no-more-often-than-X
        expiration policy, etc.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
  2. 07 Apr, 2010 1 commit
  3. 06 Apr, 2010 2 commits
  4. 18 Mar, 2010 3 commits
  5. 14 Jan, 2010 1 commit
  6. 04 Jan, 2010 2 commits
  7. 06 Nov, 2009 1 commit
    • Iustin Pop's avatar
      Fix pylint 'E' (error) codes · 6c881c52
      Iustin Pop authored
      This patch adds some silences and tweaks the code slightly so that
      “pylint --rcfile pylintrc -e ganeti” doesn't give any errors.
      The biggest change is in jqueue.py, the move of _RequireOpenQueue out of
      the JobQueue class. Since that is actually a function and not a method
      (never used as such) this makes sense, and also silences two pylint
      Another real code change is in utils.py, where FieldSet.Matches will
      return None instead of False for failure; this still works with the way
      this class/method is used, and makes more sense (it resembles more
      closely the re.match return values).
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
  8. 12 Oct, 2009 1 commit
  9. 29 Sep, 2009 1 commit
  10. 28 Sep, 2009 2 commits
  11. 25 Sep, 2009 2 commits
  12. 24 Sep, 2009 1 commit
  13. 23 Sep, 2009 4 commits
  14. 16 Sep, 2009 1 commit