Skip to content
Snippets Groups Projects
  1. Aug 22, 2012
    • Constantinos Venetsanopoulos's avatar
      Implement the External Storage Interface · 868eab67
      Constantinos Venetsanopoulos authored
      
      With this commit we introduce the External Storage Interface
      to Ganeti, abbreviated: ExtStorage Interface.
      
      The ExtStorage Interface provides Ganeti with the ability to interact
      with externally connected shared storage pools, visible by all
      VM-capable nodes. This means that Ganeti is able to handle VM disks
      that reside inside a NAS/SAN or any distributed block storage provider.
      
      The ExtStorage Interface provides a clear API, heavily inspired by the
      gnt-os-interface API, that can be used by storage vendors or sysadmins
      to write simple ExtStorage Providers (correlated to gnt-os-interface's
      OS Definitions). Those Providers will glue externally attached shared
      storage with Ganeti, without the need of preprovisioned block devices
      on Ganeti VM-capable nodes as confined be the current `blockdev' disk
      template.
      
      To do so, we implement a new disk template called `ext' (of type
      DTS_EXT_MIRROR) that passes control to externally provided scripts
      (the ExtStorage Provider) for the template's basic functions:
      
       create / attach / detach / remove / grow
      
      The scripts reside under ES_SEARCH_PATH (correlated to OS_SEARCH_PATH)
      and only one ExtStorage Provider is supported called `ext'.
      
      The disk's logical id is the tuple ('ext', UUID.ext.diskX), where UUID
      is generated as in disk template `plain' and X is the disk's index.
      
      Signed-off-by: default avatarConstantinos Venetsanopoulos <cven@grnet.gr>
      868eab67
    • Constantinos Venetsanopoulos's avatar
      Update the shared storage design document · f9a1f3eb
      Constantinos Venetsanopoulos authored
      
      Update the shared storage design document to reflect the current
      changes, after the implementation of the ExtStorage interface.
      
      Signed-off-by: default avatarConstantinos Venetsanopoulos <cven@grnet.gr>
      f9a1f3eb
    • Constantinos Venetsanopoulos's avatar
      Fix computation of disk sizes in _ComputeDiskSize · 6a3166cb
      Constantinos Venetsanopoulos authored
      
      Currently, hail fails with FailDisk when trying to add an instance
      of type: 'file', 'sharedfile' and 'rbd'.
      
      This is due to a "0" or None value in the corresponding dict inside
      _ComputeDiskSize, which results in a "O" or non Int value of the
      exported 'disk_space_total' parameter. This in turn makes hail fail,
      when trying to process the value:
      
       - with "Unable to read Int" if value is None (file)
       - with FailDisk if value is 0 (sharedfile, rbd)
      
      The latter happens because the 0 value doesn't match the instance's
      IPolicy, since it is lower than the minimum disk size.
      
      The second problem still exists when using adoption with 'plain'
      and 'blockdev' template and will be addressed in another commit.
      
      Signed-off-by: default avatarConstantinos Venetsanopoulos <cven@grnet.gr>
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      6a3166cb
  2. Aug 15, 2012
    • Iustin Pop's avatar
      Add verification of RPC results in _WipeDisks · f08e5132
      Iustin Pop authored
      
      Due to an oversight, the pause/resume sync RPC calls in _WipeDisks
      lack the verification of the overall RPC status, and directly iterate
      over the payload. The code actually doing the wipe does verify
      correctly the results. This can result in jobs failing with a hard to
      diagnose:
      
      OpExecError ['NoneType' object is not iterable]
      
      instead of proper "RPC failed" message.
      
      This patch adds a hard check on the pause call, but for the resume
      call it just logs a warning if the RPC failed; the rationale being
      that if we can't contact the node for pausing the sync, it's likely
      wiping will fail too, but after the wipe has been done, we can
      continue.
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
      f08e5132
  3. Aug 10, 2012
  4. Aug 09, 2012
  5. Aug 08, 2012
  6. Jul 27, 2012
  7. Jul 26, 2012
  8. Jul 25, 2012
  9. Jul 24, 2012
  10. Jul 23, 2012
    • Iustin Pop's avatar
      Ensure a stable content of the bash completion file · f5ce7613
      Iustin Pop authored
      
      Currently, the order of commands in the bash completion file is
      random, because the sub-commands are not sorted. This makes it harder
      to investigate the differences in packaged Ganeti or in installed
      Ganeti, since chunks in this file will have a random order.
      
      To fix this, we sort the subcommands based on the first subcommand in
      a given group ('first' also in sorted order); this results in a stable
      contents of file, as tested by building it many times and checking for
      differences.
      
      The patch also does a few other minor changes to the file
      (e.g. updating copyright years, etc.).
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
      f5ce7613
  11. Jul 19, 2012
  12. Jul 18, 2012
  13. Jul 17, 2012
Loading