Commit Graph

9 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
Alexis Lee 7d0381c91a conf: Group scheduler options
Move all scheduler options into their one of two groups. Many of the
options are simply renamed to remove their 'scheduler_' prefix, with
some exceptions:

* scheduler_default_filters -> enabled_filters
* scheduler_baremetal_default_filters -> baremetal_enabled_filters
* scheduler_driver_task_period -> periodic_task_interval
* scheduler_tracks_instance_changes -> track_instance_changes

Change-Id: I3f48e52815e80c99612bcd10cb53331a8c995fc3
Co-Authored-By: Stephen Finucane <>
Implements: blueprint centralize-config-options-ocata
7 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
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
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
Kurt Taylor d17f9ab13d Update OpenStack LLC to Foundation
Update all references of "LLC" to "Foundation".

Change-Id: I009e86784ef4dcf38882d64b0eff484576e04efe
10 years ago
Mark McLoughlin 706a137005 Use oslo-config-2013.1b4
The cfg API is now available via the oslo-config library, so switch to
it and remove the copied-and-pasted version.

Add the 2013.1b4 tarball to tools/pip-requires - this will be changed
to 'oslo-config>=2013.1' when oslo-config is published to pypi. This
will happen in time for grizzly final.

Add dependency_links to so that oslo-config can be installed
from the tarball URL specified in pip-requires.

Remove the 'deps = pep8==1.3.3' from tox.ini as it means all the other
deps get installed with easy_install which can't install oslo-config
from the URL.

Make tools/ include oslo in IMPORT_EXCEPTIONS like it already
does for paste. It turns out imp.find_module() doesn't correct handle
namespace packages.

Retain dummy file until keystoneclient middleware has been
updated (I18c450174277c8e2d15ed93879da6cd92074c27a).

Change-Id: I4815aeb8a9341a31a250e920157f15ee15cfc5bc
10 years ago
Mark McLoughlin 94d87bce21 Remove nova.config.CONF
Modules import nova.config for two reasons right now - firstly, to
reference nova.config.CONF and, secondly, if they use one of the
options defined in nova.config.

Often modules import nova.openstack.common.cfg and nova.config
which is a bit pointless since they could just use cfg.CONF if
they just want to nova.config in order to reference CONF.

Let's just use cfg.CONF everywhere and we can explicitly state
where we actually require options defined in nova.config.

Change-Id: Ie4184a74e3e78c99658becb18dce1c2087e450bb
11 years ago
Chris Behrens 2c6ab62ae2 Refactor scheduling weights.
This makes scheduling weights more plugin friendly and creates shared
code that can be used by the host scheduler as well as the future cells
scheduler.  Weighing classes can now be specified much like you can
specify scheduling host filters.

The new weights code reverses the old behavior where lower weights win.
Higher weights are now the winners.

The least_cost module and configs have been deprecated, but are still
supported for backwards compatibility.  The code has moved to
nova.scheduler.weights.least_cost and been modified to work with the new
loadable-class code.  If any of the least_cost related config options are
specified, this least_cost weigher will be used.

For those not overriding the default least_cost config values, the new
RamWeigher class will be used.  The default behavior of the RamWeigher
class is the same default behavior as the old least_cost module.

The new weights code introduces a new config option
'scheduler_weight_classes' which is used to specify which weigher classes
to use.  The default is 'all classes', but modified if least_cost
deprecated config options are used, as mentioned above.

The RamWeigher class introduces a new config option
'ram_weight_multiplier'.  The default of 1.0 causes weights equal to the
free memory in MB to be returned, thus hosts with more free memory are
preferred (causes equal spreading).  Changing this value to a negative
number such as -1.0 will cause reverse behavior (fill first).


Change-Id: I1e5e5039c299db02f7287f2d33299ebf0b9732ce
11 years ago