1. 07 Apr, 2015 1 commit
  2. 12 Sep, 2014 1 commit
  3. 02 Oct, 2013 1 commit
  4. 24 Sep, 2013 1 commit
    • Thomas Thrainer's avatar
      Replace physical_id with dynamic_params · 0c3d9c7c
      Thomas Thrainer authored
      
      
      The disk field 'physical_id' has to be kept up to date whenever a disk
      object is sent to a node via RPC. This is done with the SetDiskID method
      manually, which is a source of bugs.
      
      This patch replaces the use of 'physical_id' with a new field names
      'dynamic_params'. The RPC code is adapted to update this field whenever
      a disk object is sent to a node. Furthermore, this field is only ever
      set on copies of disk objects which don't get written to the
      configuration file. On the node side, the use of 'physical_id' is
      removed and the new dynamic parameters are used now for the same
      purpose.
      Signed-off-by: default avatarThomas Thrainer <thomasth@google.com>
      Reviewed-by: default avatarJose A. Lopes <jabolopes@google.com>
      0c3d9c7c
  5. 28 Aug, 2013 2 commits
  6. 23 Aug, 2013 1 commit
  7. 15 Jul, 2013 2 commits
    • Helga Velroyen's avatar
      Prepare verification code for new file path verification · 13a6c760
      Helga Velroyen authored
      
      
      This patch prepares the verification code for adding
      a new verification step for the file storage paths:
      - It moves a couple of file storage helper functions from
        bdev to filestorage (since they make more sense there
        and bdev is too big anyway).
      - They rename constants and functions related to the
        verification step where the allowed file paths are
        checked agains forbidden paths to a more expressive name,
        because otherwise they would be confused to be related
        to the verification of the file storage paths against
        the allowed file storage paths.
      - Use the cluster objects helper functions to check
        if file storage is inabled instead of using the utils
        function directly, because it simplifies the code.
      Signed-off-by: default avatarHelga Velroyen <helgav@google.com>
      Reviewed-by: default avatarKlaus Aehlig <aehlig@google.com>
      13a6c760
    • Helga Velroyen's avatar
      backend: remove ENABLE_FILE_STORAGE · 1f7c8208
      Helga Velroyen authored
      
      
      This patch removes the usage of the ENABLE_FILE_STORAGE
      constant in the backend code. To avoid having to pass
      it through various RPC calls, we instead move the check
      to cmdlib.
      Signed-off-by: default avatarHelga Velroyen <helgav@google.com>
      Reviewed-by: default avatarKlaus Aehlig <aehlig@google.com>
      1f7c8208
  8. 28 Jun, 2013 2 commits
  9. 07 Jun, 2013 1 commit
  10. 28 May, 2013 5 commits
  11. 23 May, 2013 2 commits
  12. 14 May, 2013 1 commit
  13. 06 May, 2013 1 commit
    • Thomas Thrainer's avatar
      Rename DRBD8 to DRBD8Dev · 239364d0
      Thomas Thrainer authored
      
      
      Right now the DRBD8 class has multiple responsibilities: a) it
      reprensents a device which can be set up, grown, etc. and b) it
      represents the whole DRBD system on a node which has a usermode helper,
      which knows how to shut down _all_ devices, etc. Therefore, the DRBD8Dev
      class will only be responsible for a device, whereas the soon to be
      extraced DRBD8 class is responsible for the DRBD system.
      Signed-off-by: default avatarThomas Thrainer <thomasth@google.com>
      Reviewed-by: default avatarHelga Velroyen <helgav@google.com>
      239364d0
  14. 24 Apr, 2013 2 commits
  15. 16 Apr, 2013 1 commit
  16. 20 Mar, 2013 1 commit
  17. 20 Feb, 2013 1 commit
  18. 12 Feb, 2013 1 commit
  19. 16 Jan, 2013 2 commits
  20. 09 Jan, 2013 1 commit
  21. 21 Dec, 2012 5 commits
  22. 20 Dec, 2012 2 commits
    • Constantinos Venetsanopoulos's avatar
      Multiple ExtStorage Providers and ext-params · 938adc87
      Constantinos Venetsanopoulos authored
      
      
      Add support for passing parameters to the ext template (ext-params).
      Take advantage of disk-params, that don't seem to make much sense in
      this template (ExtStorage Providers are not predefined and we don't
      know their needs) and use them to pass the ext-params dynamically to
      the template.
      
      ext-params are correlated with gnt-os-interface's os-params.
      All ext-params are exported to the ExtStorage Provider through it's
      environment, with variables prefixed with 'EXTP_' (similarly to the
      OS interface's 'OSP_' params).
      
      ext-params are passed via the --disk option. If the disk template
      is of type `ext', then any additional options passed to --disk and
      are not in IDISK_PARAMS are considered ext-params e.g.:
      
       gnt-instance add -t ext --disk=0:size=2G,param1=value1,param2=value2
      
      Finally, we introduce a new IDISK_PARAM called IDISK_PROVIDER, that is
      mandatory for template `ext' and is used to select the desired
      ExtStorage Provider. This parameter is not a valid --disk option for
      any other template type.
      
      The IDISK_PROVIDER parameter becomes the first element of the
      disk's unique_id tuple e.g.:
      
       unique_id = ('sample_provider1', 'UUID.ext.diskX')
      
      Example selecting different ExtStorage Providers for each disk and
      passing different ext-params to them:
      
       -t ext --disk=0:size=2G,provider=sample_provider1,param1=value1
              --disk=1:size=3G,provider=sample_provider2,param2=value2
      Signed-off-by: default avatarConstantinos Venetsanopoulos <cven@grnet.gr>
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      [iustin@google.com: small simplification in bdev code, pylint fixes]
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      938adc87
    • Constantinos Venetsanopoulos's avatar
      Implement the External Storage Interface · 376631d1
      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>
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      [iustin@google.com: small simplification in bdev code, pylint fixes]
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      376631d1
  23. 19 Dec, 2012 1 commit
  24. 12 Dec, 2012 1 commit
  25. 26 Oct, 2012 1 commit