1. 13 Nov, 2012 3 commits
  2. 12 Nov, 2012 3 commits
    • Michael Hanselmann's avatar
      RunCmd: Expose "postfork" callback · 09b72783
      Michael Hanselmann authored
      The “_postfork_fn” parameter was only used for tests until now. To
      implement a good locking scheme, remote commands must also make use of
      this callback to release a lock when the command was successfully
      started (but did not yet finish).
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
    • Iustin Pop's avatar
      Improve error message when migration status fail · 4041a4e3
      Iustin Pop authored
      Commit 6a1434d7
       (“Make migration RPC non-blocking”) changed the API
      for reporting migration status, but has a small cosmetic bug: if the
      migration status if failure, but the RPC itself to get the status
      didn't fail, it shows the following error message:
        Could not migrate instance instance2: None
      since it always uses result.fail_msg, irrespective of which part of
      the if condition failed.
      This patch simply updates the msg if not already set, leading to:
        Could not migrate instance instance2: hypervisor returned failure
      Proper error display can be done once the migration status objects can
      return failure information as well, beside status.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarHelga Velroyen <helgav@google.com>
    • Iustin Pop's avatar
      Fix type error in kvm/GetMigrationStatus · 62457f51
      Iustin Pop authored
      Commit 6a1434d7
       (“Make migration RPC non-blocking”) changed from
      raising HypervisorErrors to returning MigrationStatus
      objects. However, these objects don't have an "info" attribute, so
      they can't pass a reason back (which is in itself a bug); but the KVM
      hypervisor code attempts to do so, and fails at runtime with:
        Failed to get migration status: 'MigrationStatus' object has no attribute 'info'
      instead of the intended:
        Migration failed, aborting: too many broken 'info migrate' answers
      For now (on stable-2.6), let's just remove the "info" reason, and
      later we can add it back properly once we have a way to correctly
      represent migration status failures in the LU.
      This fixes issue 297.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
  3. 09 Nov, 2012 1 commit
  4. 08 Nov, 2012 6 commits
  5. 07 Nov, 2012 2 commits
  6. 06 Nov, 2012 10 commits
  7. 05 Nov, 2012 1 commit
    • Dato Simó's avatar
      cli.py: use None as name for tag operations on the cluster · bcd35e09
      Dato Simó authored
      This change is mostly cosmetic. Previously, the literal "cluster" was
      used for the 'name' field of tag operations on the cluster (as opposed
      to a node or an instance). Since this field has a type of TMaybeString
      specifically for the case of the cluster, it seems more correct to use
      None, rather than an arbitrary string (that is not used by the callee).
      Additionally: note in opcodes.py that groups also expect a name; the
      previous comment only referred to nodes and instances.
      Signed-off-by: default avatarDato Simó <dato@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
  8. 02 Nov, 2012 1 commit
  9. 01 Nov, 2012 5 commits
  10. 30 Oct, 2012 4 commits
  11. 29 Oct, 2012 2 commits
  12. 26 Oct, 2012 2 commits