1. 11 Feb, 2013 1 commit
  2. 08 Feb, 2013 2 commits
  3. 16 Jan, 2013 1 commit
  4. 21 Dec, 2012 1 commit
  5. 20 Dec, 2012 3 commits
    • Michael Hanselmann's avatar
      objects.NIC: Look up mode only once, capitalize acronym · 53258324
      Michael Hanselmann authored
      Look up “NIC_MODE” only once, capitalize “NIC” in error messages.
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
    • 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
      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>
    • 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
      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>
  6. 18 Dec, 2012 1 commit
  7. 20 Nov, 2012 4 commits
  8. 12 Sep, 2012 2 commits
  9. 23 Aug, 2012 2 commits
    • Iustin Pop's avatar
      Bump pep8 version to 1.2 · 5ae4945a
      Iustin Pop authored
      Debian Wheezy will ship with this version, and it has many improved checks compared to 0.6, so let's:
      - bump version in the docs
      - silence some new checks that are wrong due to our indent=2 instead of 4
      - fix lots of errors in the code where the indentation was wrong by 1
        or 2 spaces
      - fix a few cases of == True, False, None and replace with 'is'
      - re-indent some cases where the code is OK, but pep8 complains
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
    • Iustin Pop's avatar
      Change node parameter oob_program to VTYPE_STRING · 1df4d430
      Iustin Pop authored
      Since this is an inheritable parameter, having it as a MABYE_STRING
      creates only problems (per our derivation rules). We change it to
      STRING, with the default "", meaning no program. Note that most of the
      code already accepts this as valid for "no program", and some comments
      even say that this is the expected value.
      We have some other parameters like this, I'll have to investigate
      whether they need to be changed too. But right now I need this for the
      hconfd changes (it's a prerequisite for them, I forgot to send it in
      that patch series).
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
  10. 27 Jul, 2012 1 commit
  11. 19 Jul, 2012 1 commit
    • René Nussbaumer's avatar
      Fix setting ipolicy on node groups · 8b057218
      René Nussbaumer authored
      On node groups we don't have the std field. However, the InstancePolicy
      object always verifies that the std value is within a given range. As we
      fill it up with defaults if not set (as it happens to be on node groups)
      and the min value is higher than the default std value (taken from
      constants.py) we fail.
      We overcome this situation by simply let the function know if we want to
      verify the std value at all. If we don't want to verify std, we just set
      it to a compliant value (min_v) and continue.
      We also slightly adapt the error message provided, as we don't have std
      values on groups.
      Signed-off-by: default avatarRené Nussbaumer <rn@google.com>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
  12. 18 Jul, 2012 1 commit
  13. 17 Jul, 2012 1 commit
  14. 15 May, 2012 1 commit
  15. 14 May, 2012 1 commit
  16. 10 May, 2012 5 commits
  17. 18 Apr, 2012 1 commit
  18. 21 Feb, 2012 3 commits
  19. 26 Jan, 2012 4 commits
  20. 25 Jan, 2012 1 commit
  21. 24 Jan, 2012 1 commit
  22. 23 Jan, 2012 2 commits