Skip to content
Snippets Groups Projects
  1. Dec 19, 2012
  2. Nov 20, 2012
  3. Nov 13, 2012
  4. Sep 18, 2012
  5. Jul 18, 2012
    • René Nussbaumer's avatar
      Fix inconsistency in the LUXI protocol w.r.t. args · 734a2a7c
      René Nussbaumer authored
      
      This inconsistency was found during rebalancing. Hbal failed because,
      Ganeti couldn't load the opcode. After digging through the cause, an
      inconsistency with the "args" field in the LUXI protocol was triggered
      by the TemplateHaskell side where it's done uniformed.
      
      For SubmitJob and SubmitManyJobs we treat args as one argument,
      containing the job definition. In every other LUXI call args is actually
      a list of arguments. This patch fixes this consistency.
      
      This change is NOT backwards compatible.
      
      Signed-off-by: default avatarRené Nussbaumer <rn@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      734a2a7c
  6. May 08, 2012
    • Iustin Pop's avatar
      Correct capitalisation of two Luxi calls · 83c046a2
      Iustin Pop authored
      
      Two Luxi calls have inconsistent an name/value mapping (in the Python
      code):
      
      - REQ_AUTOARCHIVE_JOBS versus AutoArchiveJobs (versus AutoarchiveJobs)
      - REQ_QUEUE_SET_DRAIN_FLAG versus SetDrainFlag (no Queue)
      
      While these are only a consistency issue, let's fix them so that the
      Haskell code (which uses the auto-generated camel-case form) doesn't
      need to handle them case specially, and looks more like the Python
      code (hah, joke!).
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
      83c046a2
  7. Apr 26, 2012
  8. Feb 22, 2012
  9. Dec 21, 2011
  10. Oct 12, 2011
    • Iustin Pop's avatar
      Standardise LUXI call argument types · a629ecb9
      Iustin Pop authored
      
      Currently, we have 4 types of arguments in LUXI calls:
      
      - most common, a list of values
      - a single argument that is sent as a list of one element
      - a single argument that is sent by itself
      - a dictionary (only Query and QueryFields)
      
      This inconsistency makes it not only harder to auto-generate the
      HTools LUXI interface, but also in general to check the arguments and
      (if we ever want to do it) auto-generate the Python LUXI client.
      
      Compare this with the node daemon, which uses consistently a list for
      its arguments, and even with way more changes over time had no issues
      with extending the interface.
      
      In case we want to extend a call, there are two options:
      
      - preferred: add a new call, keep the old one unchanged
      - possible: add further parameters to the current argument list
      
      The patch against HTools will follow—sending separately as the Python
      changes are very clear by themselves.
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      a629ecb9
    • Iustin Pop's avatar
      Rename filter and filter_ to qfilter · 2e5c33db
      Iustin Pop authored
      
      We currently use 'filter' as the OpCode, QueryRequest and RAPI field
      name for representing a query filter. However, since 'filter' is a
      built-in function, we actually have to use filter_ throughout the code
      in order to not override the built-in function.
      
      This patch simply goes and does a global sed over the code. Due to the
      fact that the RAPI interface already exposed this field, we add
      compatibility code for now which handles both forms.
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      2e5c33db
  11. Aug 30, 2011
  12. May 02, 2011
  13. Mar 15, 2011
  14. Jan 07, 2011
  15. Jan 06, 2011
  16. Dec 20, 2010
  17. Dec 13, 2010
  18. Dec 01, 2010
  19. Nov 01, 2010
  20. Oct 28, 2010
  21. Aug 24, 2010
    • Michael Hanselmann's avatar
      Add simple lock monitor · 19b9ba9a
      Michael Hanselmann authored
      
      This patch adds an initial implementation of a lock monitor, accessible
      for the user through “gnt-debug locks”. It currently shows all resource
      locks: BGL, nodes and instances. Config and job queue locks could be
      shown too, but wouldn't be of much help.  The current owner(s) and mode
      are also shown.
      
      Showing pending acquires will require further changes on the SharedLock
      internals and is not yet implemented.
      
      Example output:
      $ gnt-debug locks -o name,mode,owner
      Name            Mode      Owner
      BGL/BGL         shared    JobQueue19/Job147
      instances/inst1 exclusive JobQueue19/Job147
      instances/inst2 -         -
      instances/inst3 -         -
      instances/inst4 -         -
      nodes/node1     exclusive JobQueue19/Job147
      nodes/node2     exclusive JobQueue19/Job147
      
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      19b9ba9a
  22. Jul 28, 2010
  23. May 18, 2010
    • Guido Trotter's avatar
      Abstract the LUXI eom into a constant · 25942a6c
      Guido Trotter authored
      
      Currently the EOM terminator is hardcoded on the server side, and is
      customizable in the Transport object (with the default being the same as
      the value found in the server), but not in the luxi client.
      
      With this patch we move the value to constants, and remove the "fake"
      customizability, which would just break client/server communication. If
      we ever need to have a luxi transport with a different terminator it's
      easy enough to add it back.
      
      Signed-off-by: default avatarGuido Trotter <ultrotter@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      25942a6c
  24. May 11, 2010
  25. Feb 22, 2010
  26. Jan 22, 2010
  27. Jan 05, 2010
    • Iustin Pop's avatar
      Introduce a Luxi call for GetTags · 7699c3af
      Iustin Pop authored
      
      This changes from submitting jobs to get the tags (in cli scripts) to
      queries, which (since the tags query is a cheap one) should be much
      faster.
      
      The tags queries are already done without locks (in the generic query
      paths for instances/nodes/cluster), so this shouldn't break tags query
      via gnt-* list-tags.
      
      On a small cluster, the runtime of gnt-cluster/gnt-instance list tags
      more than halves; on a big cluster (with many MCs) I expect it to be
      more than 5 times faster. The speed of the tags get is not the main
      gain, it is eliminating a job when a simple query is enough.
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
      7699c3af
  28. Jan 04, 2010
  29. Oct 13, 2009
  30. Sep 25, 2009
  31. Aug 27, 2009
  32. Aug 26, 2009
  33. Jul 19, 2009
    • Iustin Pop's avatar
      Add a luxi call for multi-job submit · 56d8ff91
      Iustin Pop authored
      
      As a workaround for the job submit timeouts that we have, this patch
      adds a new luxi call for multi-job submit; the advantage is that all the
      jobs are added in the queue and only after the workers can start
      processing them.
      
      This is definitely faster than per-job submit, where the submission of
      new jobs competes with the workers processing jobs.
      
      On a pure no-op OpDelay opcode (not on master, not on nodes), we have:
        - 100 jobs:
          - individual: submit time ~21s, processing time ~21s
          - multiple:   submit time 7-9s, processing time ~22s
        - 250 jobs:
          - individual: submit time ~56s, processing time ~57s
                        run 2:      ~54s                  ~55s
          - multiple:   submit time ~20s, processing time ~51s
                        run 2:      ~17s                  ~52s
      
      which shows that we indeed gain on the client side, and maybe even on
      the total processing time for a high number of jobs. For just 10 or so I
      expect the difference to be just noise.
      
      This will probably require increasing the timeout a little when
      submitting too many jobs - 250 jobs at ~20 seconds is close to the
      current rw timeout of 60s.
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
      (cherry picked from commit 2971c913)
      56d8ff91
  34. Jul 07, 2009
Loading