Skip to content
Snippets Groups Projects
  1. Sep 03, 2009
  2. Aug 31, 2009
  3. Aug 28, 2009
  4. Aug 26, 2009
  5. Aug 24, 2009
  6. Aug 18, 2009
  7. Aug 17, 2009
  8. Aug 14, 2009
  9. Aug 13, 2009
  10. Aug 10, 2009
  11. Aug 06, 2009
  12. Aug 05, 2009
    • Iustin Pop's avatar
      export: add meaningful exit code · 084f05a5
      Iustin Pop authored
      
      Currently ‘gnt-backup export’ always returns exit code zero, even in the
      face of complete failure during backup (only failure to stop/start the
      instance will cause job failure and thus non-zero exit code). This is
      bad, since one cannot script the backup.
      
      This patch adds some simple results from the LU so that the command line
      script can return good exit code. It will:
        - return zero for full success (snapshot removal errors are ignored
          though)
        - return one for full failure (finalize export failure or all disks
          failure)
        - return two for partial failure (some disks backed up, some not)
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      084f05a5
  13. Aug 04, 2009
  14. Aug 03, 2009
  15. Jul 31, 2009
  16. Jul 22, 2009
  17. Jul 19, 2009
  18. Jul 16, 2009
    • Guido Trotter's avatar
      b119bccb
    • Guido Trotter's avatar
      Get rid of the default_hypervisor slot · 066f465d
      Guido Trotter authored
      
      Currently we have both a default_hypervisor and an enabled_hypervisors
      list. The former is only settable at cluster init time, while the latter
      can be changed with cluster modify.
      
      This becomes cumbersome in a few ways: at cluster init time for example
      if we pass in a list of enabled hypervisors which doesn't include the
      "default" xen-pvm one, we're also forced to pass a default hypervisor,
      or an error will be reported. It is also currently possible to disable
      the default hypervisor in cluster-modify (with unknown results).
      
      In order to avoid this we get rid of this field altogether, and define
      the "first" enabled hypervisor as the default one. This allows ease of
      changing which one is the default, and at the same time maintains
      coherency.
      
      At configuration upgrade we make sure that the old default is first in
      the list, so that 2.0 cluster defaults are preserved.
      
      Signed-off-by: default avatarGuido Trotter <ultrotter@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      066f465d
  19. Jul 08, 2009
Loading