1. 12 May, 2014 8 commits
  2. 09 May, 2014 14 commits
  3. 08 May, 2014 8 commits
  4. 06 May, 2014 5 commits
    • Klaus Aehlig's avatar
      Recursively clear serial numbers · c877d159
      Klaus Aehlig authored
      
      
      Disk objects, in general, are of recursive nature. Therefore,
      when downgrading them, do so recursively.
      Signed-off-by: default avatarKlaus Aehlig <aehlig@google.com>
      Reviewed-by: default avatarHrvoje Ribicic <riba@google.com>
      c877d159
    • Klaus Aehlig's avatar
      Make upgrade more robust · aff02701
      Klaus Aehlig authored
      
      
      Depending on where we're upgrading from, disks may or may
      not have been moved to top-level status. So use the more robust
      order of first outlining disks and only then fixing indices
      within the disk description.
      Signed-off-by: default avatarKlaus Aehlig <aehlig@google.com>
      Reviewed-by: default avatarPetr Pudlak <pudlak@google.com>
      aff02701
    • Klaus Aehlig's avatar
      Fix order in downgrades · cdda6dfc
      Klaus Aehlig authored
      
      
      We first have to downgrade the disks before inlining them
      to the instances.
      Signed-off-by: default avatarKlaus Aehlig <aehlig@google.com>
      Reviewed-by: default avatarPetr Pudlak <pudlak@google.com>
      cdda6dfc
    • Klaus Aehlig's avatar
      Simplify cleanup of locks · 0d730682
      Klaus Aehlig authored
      
      
      Since, from stable-2.12 onwards, locks are no longer explicitly
      added and removed, there is no need to release them separately.
      The freeing of all locks of the level left will take care of this
      anyway.
      Signed-off-by: default avatarKlaus Aehlig <aehlig@google.com>
      Reviewed-by: default avatarPetr Pudlak <pudlak@google.com>
      0d730682
    • Klaus Aehlig's avatar
      Handle lock addition as lock acquisitions · bb38965c
      Klaus Aehlig authored
      
      
      From stable-2.12 onwards no longer are explicitly added; they just
      exist for all conceivable names/uuids. Nevertheless, addition was
      handled special based on the assumption that no one else can have
      a lock on an entity that is just being created.
      
      This assumption, however, is wrong for instance names. Consider
      the situation that an instance is first destroyed an then an instance
      with the same name is created. While is instance is being destroyed,
      there is the situation where the instance is still in the configuration
      and the destroy job holds a lock on the instance. In that time, another
      job, like group_verify_disks, can read the list of instances, decide
      to wait for a lock on all the then existing instances, and eventually
      get the locks, including the one on the instance just removed. And
      while that job still has the (useless) lock, the new creation job can
      come to the lock-addition stage.
      
      To live with the presence of those races, just wait for newly added
      locks as for any other locks. Any job with a lock on a no longer existing
      entity will release it pretty soon anyway.
      Signed-off-by: default avatarKlaus Aehlig <aehlig@google.com>
      Reviewed-by: default avatarPetr Pudlak <pudlak@google.com>
      bb38965c
  5. 05 May, 2014 5 commits