Skip to content
Snippets Groups Projects
  1. Jan 05, 2012
  2. Dec 09, 2011
  3. Dec 08, 2011
  4. Dec 01, 2011
  5. Nov 22, 2011
  6. Nov 04, 2011
  7. Nov 03, 2011
  8. Oct 31, 2011
  9. Oct 17, 2011
  10. Sep 22, 2011
  11. Aug 30, 2011
  12. Aug 04, 2011
    • Michael Hanselmann's avatar
      173dbf05
    • Michael Hanselmann's avatar
      ganeti-watcher: Split for node groups · 16e0b9c9
      Michael Hanselmann authored
      
      This patch brings a huge change to ganeti-watcher to make it aware of
      node groups. Each node group is processed in its own subprocess,
      reducing the impact of long-running operations.
      
      The global watcher state file, $datadir/ganeti/watcher.data, is replaced
      with a state file per node group ($datadir/ganeti/watcher.${uuid}.data).
      
      Previously a lock on the state file was used to ensure only one instance
      of watcher was running at the same time. Some operations, e.g.
      “gnt-cluster renew-crypto”, blocked the watcher by acquiring an
      exclusive lock on the state file. Since the watcher processes now use
      different files, this method is no longer usable. Locking multiple files
      isn't atomic. Instead a dedicated lock file is used and every watcher
      process acquires a shared lock on it. If a Ganeti command wants to block
      the watcher it acquires the lock in exclusive mode.
      
      Each per-nodegroup watcher process also acquires an exclusive lock on
      its state file. This prevents multiple watchers from running for the
      same nodegroup.
      
      The code is reorganized heavily to clear up dependencies between
      functions and to get rid of the global “client” variable. The utility
      class “Watcher” is removed in favour of stand-alone utility functions.
      
      Since the parent watcher process won't wait for its children by
      default, a new option (--wait-children) was added. It is used, for
      example, by QA.
      
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      16e0b9c9
  13. Jul 29, 2011
  14. Jul 28, 2011
  15. Jul 27, 2011
  16. Jul 25, 2011
  17. Jul 21, 2011
  18. May 16, 2011
  19. Apr 21, 2011
  20. Apr 14, 2011
  21. Apr 06, 2011
  22. Apr 01, 2011
  23. Mar 15, 2011
  24. Mar 08, 2011
  25. Mar 03, 2011
    • René Nussbaumer's avatar
      LUInstanceRename: Fail if renamed hostname mismatch · 31fe5102
      René Nussbaumer authored
      
      There's a problem if you run gnt-instance rename with a non FQDN and the
      renamed LU tries to resolve the hostname to make it FQDN. It could be
      that this resolved hostname was just a CNAME to another name which leads
      to wrongly renamed instances name.
      
      Given a name of "foobar" is a CNAME to "moohost" now if you gonna rewrite an
      instance named "foobar1" to "foobar" it will pickup the host "moohost".
      This is not obvious behaviour. If we detect this case we abort with a
      prereq error. The user then however can continue with a FQDN and
      --no-name-check if he intends to force the operation.
      
      Signed-off-by: default avatarRené Nussbaumer <rn@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      31fe5102
  26. Feb 28, 2011
  27. Feb 25, 2011
  28. Feb 24, 2011
  29. Feb 18, 2011
Loading