Commit Graph

11 Commits (master)

Author SHA1 Message Date
Yikun Jiang e66443770d Per aggregate scheduling weight
This spec proposes to add ability to allow users to use
``Aggregate``'s ``metadata`` to override the global config options
for weights to achieve more fine-grained control over resource

blueprint: per-aggregate-scheduling-weight

Change-Id: I6e15c6507d037ffe263a460441858ed454b02504
4 years ago
EdLeafe 5dbdd6ed2b Config options: centralize section "scheduler"
This change moves all of the configuration options previously defined in
nova/scheduler to the new centralized nova/conf/scheduler directory.

A subsequent patch will then improve the help texts.

Blueprint centralize-config-options
Change-Id: I08d50e873f71601a26ce768feac635243d0570f4
8 years ago
Sylvain Bauza ccea5d6b0a Fix NoneType error when calling MetricsWeigher
Given that dict comprehensions don't allow to have None as a list, we had
a problem with the Ironic gate-ironic-inspector-dsvm job because
host_state.metrics was set to None by default.

Adding a unittest to make sure we don't regress.

Closes-Bug: #1499271
Change-Id: I6e3104bbd9b9865ec2dcc724c2f56da6d0b2b687
8 years ago
Yingxin Cheng fd2b868d41 Fix MetricWeigher to use MonitorMetricList
The commit I4dfbea27ce6c3eecc1a8658b1f9dc0feb2298705 changes
'HostState.metrics' to 'objects.MonitorMetricList'. But MetricWeigher
still use the old dictionary of 'host_manager.MetricItem'. This patch
corrects the behavior of MetricWeigher with related tests, and delete
unused MetricItem.

Co-Authored-By: Sylvain Bauza <>

Change-Id: I7c98c2e189318e85a733f0287ef507c7bad36472
Closes-Bug: #1493680
8 years ago
Davanum Srinivas af2d6c9576 Switch to using oslo_* instead of oslo.*
The oslo team is recommending everyone to switch to the
non-namespaced versions of libraries. Updating the hacking
rule to include a check to prevent oslo.* import from
creeping back in.

This commit includes:
- using oslo_utils instead of oslo.utils
- using oslo_serialization instead of oslo.serialization
- using oslo_db instead of oslo.db
- using oslo_i18n instead of oslo.i18n
- using oslo_middleware instead of oslo.middleware
- using oslo_config instead of oslo.config
- using oslo_messaging instead of "from oslo import messaging"
- using oslo_vmware instead of oslo.vmware

Change-Id: I3e2eb147b321ce3e928817b62abcb7d023c5f13f
8 years ago
Lianhao Lu 717f849b60 MetricsWeigher: Added support of unavailable metrics
This patch added the support of unavailable metrics in the metric
weigher. Based on the configuration, if an unavailable metric is met,
the metric weigher might either throw an exception, or return an
configurable weight value.

This is part of the blueprint utilization-aware-scheduling.

DocImpact: Added support of unavailable metrics. 2 new config options
are added, 1) 'required' is a boolean option indicating whether all
the metrics set by 'weight_setting' are needed to be available when
calculating the weight. 2) 'weight_of_unavailable' is a float option
specifying the value to be returned if the metrics is unavailable. See
etc/nova/nova.conf.sample for details.

Change-Id: Icb951605aae28487b00a12d172a3ac4dafda2cdb
9 years ago
Jenkins 80af73c36b Merge "Corrected typo in metrics" 9 years ago
Lianhao Lu e8faf3a2a6 Added a new scheduler filter for metrics
The scheduler filter MetricsFilter filters out those hosts which don't
have the metrics data available as required by metric settings.

This is part of the blueprint utilization-aware-scheduling.

DocImpact: Added a new metrics filter.

Change-Id: Ib4a898774daf683c4496ef3e9953d23027f11ac0
10 years ago
Shuangtai Tian 66ada2800b Corrected typo in metrics
Change-Id: If23292d83776be50f22f45c849fd45b7b04da7d9
10 years ago
Alvaro Lopez Garcia e5ba849437 Normalize the weights instead of using raw values
The weight system is being used by the scheduler and the cells code.
Currently this system is using the raw values instead of normalizing them.
This makes difficult to properly use multipliers for establishing the
relative importance between two wheighers (one big magnitude could
shade a smaller one). This change introduces weight normalization so

- From an operator point of view we can prioritize the weighers that
  we are applying. The only way to do this is being sure that all the
  weighers will give a value in a known range, so that it is
  not needed to artificially use a huge multiplier to prioritize a

- From a weigher developer point of view, somebody willing to implement
  one has to care about 1) returning a list of values, 2) setting the
  minimum and maximum values where the weights can range, if they are
  needed and they are significant for the weighing. For a weigher
  developer there are two use cases:

    Case 1: Use of a percentage instead of absolute values (for example, %
    of free RAM). If we compare two nodes focusing on the percentage of free
    ram, the maximum value for the weigher is 100. If we have two nodes one
    with 2048 total/1024 free, and the second one 1024 total/512 free they
    will get both the same weight, since they have the same % of free RAM
    (that is, the 50%).

    Case 2: Use of absolute values. In this case, the maximum of the weigher
    will be the maximum of the values in the list (in the case above, 1024)
    or the maximum value that the magnitude could take (in the case above,
    2048). How this maximum is set, is a decision of the developer. He may
    let the operator choose the behaviour of the weigher though.

- From the point of view of the scheduler we ensure that it is using
  normalized values, and not leveraging the normalization mechanism to the

Changes introduced this commit:

1) it introduces weight normalization so that we can apply multipliers
   easily. All the weights for an object will be normalized between 0.0 and
   1.0 before being sumed up, so that the final weight for a host will be:

    weight = w1_multiplier * norm(w1) + w2_multiplier * norm(w2) + ...

2) weights.BaseWeigher has been changed into an ABC so that we enforce
   that all weighers have the expected methods.

3) weights.BaseWeigher.weigh_objects() does no longer sum up the
   computer weighs to the object, but it rather returns a list that will be
   then normalized and added to the existing weight by BaseWeightHandler

4) Adapt the existing weighers to the above changes. Namely
    - New 'offset_weight_multiplier' for the cell weigher
    - Changed the name of the existing multiplier methods.

5) unittests for all of the introduced changes.

Implements blueprint normalize-scheduler-weights

DocImpact: Now weights for an object are normalized before suming them
up. This means that each weigher will take a maximum value of 1. This
may have an impact for operators that are using more than one weigher
(currently there is only one weigher: RAMWeiger) and for operators using
cells (where we have several weighers). It is needed to review then the
multipliers used and adjust them properly in case they have been

Docimpact: There is a new configuration option 'offset_weight_multiplier'
in nova.cells.weights.weight_offset.WeightOffsetWeigher

Change-Id: I81bf90898d3cb81541f4390596823cc00106eb20
10 years ago
Lianhao Lu bc32777e73 Added a new scheduler metrics weight plugin
The new metrics weigher can compute the weight based on the compute
node host's metrics data. The to-be weighed metrics and their
weighing ratio are specified in the configuration file as the

    metrics_weight_setting = name1=1.0,name2=-1.0

The final weight would be name1.value * 1.0 + name2.value * (-1.0).

This is part of the blueprint utilization-aware-scheduling.


Change-Id: Ib3e68505e6d4d8f6d67b54c5f00de3e1c172738c
10 years ago