Skip to content
Snippets Groups Projects
  1. Jan 06, 2012
  2. Dec 21, 2011
    • Michael Hanselmann's avatar
      jqueue: Fix deadlock between job queue and dependency manager · 37d76f1e
      Michael Hanselmann authored
      
      When an opcode is about to be processed its dependencies are
      evaluated using “_JobDependencyManager.CheckAndRegister”. Due
      to its nature that function requires a lock on the manager's
      internal structures. All of this happens while the job queue
      lock is held in shared mode (required for the job processor).
      
      When a job has been processed any pending dependencies are re-added
      to the job workerpool. Before this patch that would require
      the manager's lock and then, for adding the jobs, the job queue
      lock. Since this is in reverse order it will lead to deadlocks.
      
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      37d76f1e
  3. Nov 30, 2011
  4. Nov 24, 2011
    • Michael Hanselmann's avatar
      LUGroupAssignNodes: Fix node membership corruption · 54c31fd3
      Michael Hanselmann authored
      
      Note: This bug only manifests itself in Ganeti 2.5, but since the
      problematic code also exists in 2.4, I decided to fix it there.
      
      If a node was assigned to a new group using “gnt-group assign-nodes” the
      node object's group would be changed, but not the duplicate member list
      in the group object. The latter is an optimization to require fewer
      locks for other operations. The per-group member list is only kept in
      memory and not written to disk.
      
      Ganeti 2.5 starts to make use of the data kept in the per-group member
      list and consequently fails when it is out of date. The following
      commands can be used to reproduce the issue in 2.5 (in 2.4 the issue was
      confirmed using additional logging):
      
        $ gnt-group add foo
        $ gnt-group assign-nodes foo $(gnt-node list --no-header -o name)
        $ gnt-cluster verify  # Fails with KeyError
      
      This patch moves the code modifying node and group objects into
      “config.ConfigWriter” to do the complete operation under the config
      lock, and also to avoid making use of side-effects of modifying objects
      without calling “ConfigWriter.Update”. A unittest is included.
      
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      (cherry picked from commit 218f4c3d)
      54c31fd3
    • Michael Hanselmann's avatar
      LUGroupAssignNodes: Fix node membership corruption · 218f4c3d
      Michael Hanselmann authored
      
      Note: This bug only manifests itself in Ganeti 2.5, but since the
      problematic code also exists in 2.4, I decided to fix it there.
      
      If a node was assigned to a new group using “gnt-group assign-nodes” the
      node object's group would be changed, but not the duplicate member list
      in the group object. The latter is an optimization to require fewer
      locks for other operations. The per-group member list is only kept in
      memory and not written to disk.
      
      Ganeti 2.5 starts to make use of the data kept in the per-group member
      list and consequently fails when it is out of date. The following
      commands can be used to reproduce the issue in 2.5 (in 2.4 the issue was
      confirmed using additional logging):
      
        $ gnt-group add foo
        $ gnt-group assign-nodes foo $(gnt-node list --no-header -o name)
        $ gnt-cluster verify  # Fails with KeyError
      
      This patch moves the code modifying node and group objects into
      “config.ConfigWriter” to do the complete operation under the config
      lock, and also to avoid making use of side-effects of modifying objects
      without calling “ConfigWriter.Update”. A unittest is included.
      
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      218f4c3d
  5. Nov 08, 2011
  6. Oct 18, 2011
  7. Oct 17, 2011
  8. Oct 04, 2011
  9. Sep 30, 2011
  10. Aug 26, 2011
  11. Aug 23, 2011
  12. Aug 19, 2011
  13. Aug 12, 2011
  14. Aug 11, 2011
  15. Aug 09, 2011
  16. Aug 08, 2011
    • Michael Hanselmann's avatar
      Detect globbing patterns as query arguments · f8638e28
      Michael Hanselmann authored
      
      Short: this patch enables the use of “gnt-instance list '*.site'”.
      
      Detailed description: This patch changes the command line interface code
      to try to deduce the kind of filter from the arguments to a “list”
      command. If it's a list of plain names an old-style name filter is used.
      If filtering is forced or the single argument is potentially a filter,
      it is parsed as a query filter string. Any name looking like a globbing
      pattern (e.g. “*.site” or “web?.example.com”) is treated as such.
      
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      f8638e28
  17. Aug 05, 2011
  18. Aug 04, 2011
  19. Aug 02, 2011
  20. Jul 26, 2011
  21. Jul 25, 2011
  22. Jul 21, 2011
  23. Jul 20, 2011
    • Michael Hanselmann's avatar
      jqueue: Add “writable” flag to memory objects · c0f6d0d8
      Michael Hanselmann authored
      
      Basically only one instance of the job, the one being processed,
      should be serialized to disk and replicated to other nodes. With
      this flag assertions can be added in various places.
      
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      c0f6d0d8
    • Michael Hanselmann's avatar
      Implement chained jobs · b95479a5
      Michael Hanselmann authored
      
      An overview is available in the design document for this change,
      doc/design-chained-jobs.rst.
      
      When a job enters the job processor, the current opcode's dependencies
      are evaluated. If a referenced job has not yet reached the desired
      status, the current job is registered as a dependant. The job processor
      will continue to work on other pending tasks. When a job finishes it
      notifies any pending dependants by re-adding them to the workerpool.
      
      A per-job processor lock is necessary for rare cases where the same job
      can be re-added twice.
      
      There is no way to view waiting jobs at the moment, but I plan to
      export this information to “gnt-debug locks”.
      
      A so-called dependency manager takes care of managing waiting jobs and
      keeping track of their status.
      
      Unittests are included.
      
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      b95479a5
  24. Jul 15, 2011
  25. Jul 12, 2011
  26. Jul 11, 2011
  27. Jul 05, 2011
Loading