From a63217654b56da045302eec9f112fb281254efa2 Mon Sep 17 00:00:00 2001 From: Bernardo Dal Seno <bdalseno@google.com> Date: Wed, 20 Mar 2013 01:48:07 +0100 Subject: [PATCH] Amend partitioned design doc for multiple ispecs There will be only one standard specification in instance policies. Signed-off-by: Bernardo Dal Seno <bdalseno@google.com> Reviewed-by: Guido Trotter <ultrotter@google.com> --- doc/design-partitioned.rst | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/doc/design-partitioned.rst b/doc/design-partitioned.rst index 0c4bc43d9..c059ccd8f 100644 --- a/doc/design-partitioned.rst +++ b/doc/design-partitioned.rst @@ -163,10 +163,12 @@ defined at node-group level. Currently it's possible to define an instance policy that limits the minimum and maximum value for CPU, memory, and disk usage (and spindles and any other resource, when implemented), independently from each other. We -extend the policy by allowing it to specify more specifications, where -each specification contains the limits (minimum, maximum, and standard) -for all the resources. Each specification has a unique priority (an -integer) associated to it, which is used by ``hspace`` (see below). +extend the policy by allowing it to contain more occurrences of the +specifications for both the limits for the instance resources. Each +specification pair (minimum and maximum) has a unique priority +associated to it (or in other words, specifications are ordered), which +is used by ``hspace`` (see below). The standard specification doesn't +change: there is one for the whole cluster. For example, a policy could be set up to allow instances with this constraints: @@ -183,12 +185,11 @@ Ganeti will refuse to create (or modify) instances that violate instance policy constraints, unless the flag ``--ignore-ipolicy`` is passed. While the changes needed to check constraint violations are -straightforward, ``hspace`` behavior needs some adjustments. For both -standard and tiered allocation, ``hspace`` will start to allocate -instances using the specification with the highest priority, then it -will fall back to second highest priority, and so on. For tiered -allocation, it will try to lower the most constrained resources (without -breaking the policy) before going to the next specification. +straightforward, ``hspace`` behavior needs some adjustments for tiered +allocation. ``hspace`` will start to allocate instances using the +maximum specification with the highest priority, then it will try to +lower the most constrained resources (without breaking the policy) +before moving to the second highest priority, and so on. For consistent results in capacity calculation, the specifications inside a policy should be ordered so that the biggest specifications -- GitLab