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 weights. 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 <sbauza@redhat.com> 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 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
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 followings: 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. DocImpact Change-Id: Ib3e68505e6d4d8f6d67b54c5f00de3e1c172738c	10 years ago