Skip to content

GitLab

Switch branch/tag
  1. 16 Jan, 2013 1 commit
  3. 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>
      53258324
    • 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
  7. 18 Dec, 2012 1 commit
  9. 20 Nov, 2012 4 commits
  11. 12 Sep, 2012 2 commits
  13. 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>
      5ae4945a
    • 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>
      1df4d430
  15. 27 Jul, 2012 1 commit
  17. 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>
      8b057218
  19. 18 Jul, 2012 1 commit
  21. 17 Jul, 2012 1 commit
  23. 15 May, 2012 1 commit
  25. 14 May, 2012 1 commit
  27. 10 May, 2012 5 commits
  29. 18 Apr, 2012 1 commit
  31. 21 Feb, 2012 3 commits
  33. 26 Jan, 2012 4 commits
  35. 25 Jan, 2012 1 commit
  37. 24 Jan, 2012 1 commit
  39. 23 Jan, 2012 2 commits
  41. 13 Jan, 2012 2 commits
    • Iustin Pop's avatar
      Further fixes to instance policy validation · 57dc299a
      Iustin Pop authored 
      

As a followup from "Remove extraneous check in policy creation", there
are more places where we build an ipolicy, and then manually check for
its validity. This is very bad style, as it duplicates the
verification code across many places.

This patch removes all such explicit checks (except for one in
cmdlib.py which is correct), and instead does a bit more validation in
the builder functions or in the actual dedicated verification
functions. It also fixes cluster init which used the wrong,
non-completed ipolicy (this was not detected before as we did call
check on it, but otherwise we ignored it), and fixes a too-strong
assert (due to the call chain, we first create the ipolicy from
cmdline params, and only then we fill it).

Finally, it removes an extraneous logging.info which I forgot from
debugging.
Signed-off-by: default avatarIustin Pop <iustin@google.com>
Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
      57dc299a
    • Iustin Pop's avatar
      Add new disk_templates parameter to instance policy · 2cc673a3
      Iustin Pop authored 
      

This is a bit more complex patch, as it requires changing the
assumption that all keys in the policy dict points to values that are
themselves dicts. Right now we introduce an assumption that any
non-dicts are lists, we'll see in the future if this holds or whether
we need more complex type checking (manual, yay Python).

The patch also does some trivial style changes.
Signed-off-by: default avatarIustin Pop <iustin@google.com>
Reviewed-by: default avatarRené Nussbaumer <rn@google.com>
      2cc673a3
  43. 11 Jan, 2012 1 commit