Skip to content
Snippets Groups Projects
  1. Mar 19, 2012
  2. Jan 19, 2012
  3. Oct 31, 2011
  4. Oct 17, 2011
  5. Sep 22, 2011
  6. Aug 30, 2011
  7. 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
  8. Jul 29, 2011
  9. Jul 28, 2011
  10. Jul 27, 2011
  11. Jul 25, 2011
  12. Jul 21, 2011
  13. May 16, 2011
  14. Apr 21, 2011
  15. Apr 14, 2011
  16. Apr 06, 2011
  17. Apr 01, 2011
  18. Mar 15, 2011
  19. Mar 08, 2011
  20. 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
  21. Feb 28, 2011
  22. Feb 25, 2011
  23. Feb 24, 2011
  24. Feb 18, 2011
  25. Feb 16, 2011
  26. Feb 03, 2011
  27. Jan 31, 2011
Loading