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 weights. 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 <sfinucan@redhat.com> 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 that: - 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 weigher. - 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 weighers. 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 nova.cells.weights.weight_offset.WeightOffsetWeigher - 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 modified. 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 setup.py 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/hacking.py 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 cfg.py 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). DocImpact Change-Id: I1e5e5039c299db02f7287f2d33299ebf0b9732ce	11 years ago