commit 705284e18c3a9f2c93ecb15bd1bfee5d7710b684
Author: Matt Riedemann <email address hidden>
Date: Thu Aug 30 17:57:24 2018 -0400
Don't persist zero allocation ratios in ResourceTracker
The ComputeNode object itself has a facade which provides the
actual default values for cpu, disk and ram allocation ratios
when the config option values are left at the default (0.0).
When we initially create a ComputeNode in the ResourceTracker,
the *_allocation_ratio values in the object are going to be
unset, and then _copy_resources, called from _init_compute_node,
will set the values to the config option values, again, defaulted
to 0.0, but the ComputeNode object, after calling create() or
save(), will change those *on the object* to the non-0.0 we
actually know and love (16.0 for cpu, 1.5 for ram, and 1.0 for disk).
During the update_available_resource periodic, we'll again go
through _init_compute_node and _copy_resources in the ResourceTracker
which will set the configured values (default of 0.0) onto the
ComputeNode object, which makes the _resource_change method, called
from _update, return True and trigger a ComputeNode.save() call
from the _update method. At that point we're *persisting* the 0.0
allocation ratios in the database, even though ComputeNode.save
will change them to their non-0.0 default values *on the object*
because of the _from_db_object call at the end of ComputeNode.save.
So even if the ComputeNode object allocation ratio values are the
non-0.0 defaults, we'll *always* update the database on every
periodic even if nothing else changed in inventory.
This change modifies the _copy_resource method to only update the
ComputeNode fields if the configured ratios are not the 0.0 default.
Change-Id: I43a23a3290db0c835fed01b8d6a38962dc61adce
Related-Bug: #1789654
(cherry picked from commit 2588af87c862cfd02d860f6b860381e907b279ff)
(cherry picked from commit 01265b98c4cd2b1377e891a06ce748fc6f8f3425)
Reviewed: https:/ /review. openstack. org/613271 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=705284e18c3 a9f2c93ecb15bd1 bfee5d7710b684
Committed: https:/
Submitter: Zuul
Branch: stable/queens
commit 705284e18c3a9f2 c93ecb15bd1bfee 5d7710b684
Author: Matt Riedemann <email address hidden>
Date: Thu Aug 30 17:57:24 2018 -0400
Don't persist zero allocation ratios in ResourceTracker
The ComputeNode object itself has a facade which provides the
actual default values for cpu, disk and ram allocation ratios
when the config option values are left at the default (0.0).
When we initially create a ComputeNode in the ResourceTracker,
the *_allocation_ratio values in the object are going to be
unset, and then _copy_resources, called from _init_compute_node,
will set the values to the config option values, again, defaulted
to 0.0, but the ComputeNode object, after calling create() or
save(), will change those *on the object* to the non-0.0 we
actually know and love (16.0 for cpu, 1.5 for ram, and 1.0 for disk).
During the update_ available_ resource periodic, we'll again go
through _init_compute_node and _copy_resources in the ResourceTracker
which will set the configured values (default of 0.0) onto the
ComputeNode object, which makes the _resource_change method, called
from _update, return True and trigger a ComputeNode.save() call
from the _update method. At that point we're *persisting* the 0.0
allocation ratios in the database, even though ComputeNode.save
will change them to their non-0.0 default values *on the object*
because of the _from_db_object call at the end of ComputeNode.save.
So even if the ComputeNode object allocation ratio values are the
non-0.0 defaults, we'll *always* update the database on every
periodic even if nothing else changed in inventory.
This change modifies the _copy_resource method to only update the
ComputeNode fields if the configured ratios are not the 0.0 default.
Change-Id: I43a23a3290db0c 835fed01b8d6a38 962dc61adce 02d860f6b860381 e907b279ff) 377e891a06ce748 fc6f8f3425)
Related-Bug: #1789654
(cherry picked from commit 2588af87c862cfd
(cherry picked from commit 01265b98c4cd2b1