Skip to content
Snippets Groups Projects
  1. Jan 10, 2011
    • Adeodato Simo's avatar
      Add unit test for ganeti.rapi.client's ModifyGroup · 7187e6ff
      Adeodato Simo authored
      
      This was forgotten in f18fab7d.
      
      Signed-off-by: default avatarAdeodato Simo <dato@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      7187e6ff
    • Iustin Pop's avatar
      Generalize the OpCode-should-be-in-mcpu test · 687c10d9
      Iustin Pop authored
      
      Currently, the unittest TestDispatchTable in mcpu unittest does a
      hard-coded approach to test whether an opcode should be included or
      not in the mcpu.Processor dispatch table. This is not flexible, so we
      replace it with two changes:
      
      - first, we do not return the base OpCode in opcodes.OP_MAPPING;
        rationale being that we shouldn't need to serialise or deserialise
        this opcode during normal operation
      - second, we add a new attribute WITH_LU (other name suggestions
        welcome) to the base opcode set to True, and we explicitly set it to
        False in OpTestDummy, thus automatic skipping of such LUs in the
        unittest (and in other places)
      
      To correct for the new behaviour, the tests in the opcode unittests
      are updated to include OpCode explicitly.
      
      Note: we also replace assert_ with assertTrue in the affected unittest
      (as assert_ is deprecated in 2.7).
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      687c10d9
  2. Jan 07, 2011
  3. Jan 06, 2011
  4. Jan 05, 2011
  5. Jan 04, 2011
  6. Dec 30, 2010
  7. Dec 29, 2010
  8. Dec 21, 2010
  9. Dec 17, 2010
  10. Dec 15, 2010
    • Michael Hanselmann's avatar
      jqueue: Keep jobs in “waitlock” while returning to queue · 5fd6b694
      Michael Hanselmann authored
      
      Iustin Pop reported that a job's file is updated many times while it
      waits for locks held by other thread(s). After an investigation it was
      concluded that the reason was a design decision for job priorities to
      return jobs to the “queued” status if they couldn't acquire all locks.
      Changing a jobs' status or priority requires an update to permanent
      storage.
      
      In a high-level view this is what happens:
      1. Mark as waitlock
      2. Write to disk as permanent storage (jobs left in this state by a
         crashing master daemon are resumed on restart)
      3. Wait for lock (assume lock is held by another thread)
      4. Mark as queued
      5. Write to disk again
      6. Return to workerpool
      
      Another option originally discussed was to leave the job in the
      “waitlock” status. Ignoring priority changes, this is what would happen:
      1. If not in waitlock
      1.1. Assert state == queued
      1.2. Mark as waitlock
      1.3. Set start_timestamp
      1.4. Write to disk as permanent storage
      3. Wait for locks (assume lock is held by another thread)
      4. Leave in waitlock
      5. Return to workerpool
      
      Now let's assume the lock is released by the other thread:
      […]
      3. Wait for locks and get them
      4. Assert state == waitlock
      5. Set state to running
      6. Set exec_timestamp
      7. Write to disk
      
      As this change reduces the number of writes from two per lock acquire
      attempt to two per opcode and one per priority increase (as happens
      after 24 acquire attempts (see mcpu._CalculateLockAttemptTimeouts) until
      the highest priority is reached), here's the patch to implement it.
      Unittests are updated.
      
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      5fd6b694
    • Michael Hanselmann's avatar
      Improve jqueue unittests · ebb2a2a3
      Michael Hanselmann authored
      
      - Verify job file updates
      - Ensure queue lock is released while executing opcode
      
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      ebb2a2a3
  11. Dec 14, 2010
  12. Dec 13, 2010
  13. Dec 10, 2010
  14. Dec 08, 2010
  15. Dec 06, 2010
  16. Dec 01, 2010
  17. Nov 29, 2010
Loading