The purpose of the RT._normalize_inventory_from_cn_obj method is
to set allocation_ratio and reserved amounts on standard resource
class inventory records that get sent to placement if the virt driver
did not specifically set a ratio or reserved value (which none but
the ironic driver do).
If the allocation_ratio or reserved amount is in the inventory
data dict from the virt driver, then the normalize method ignores
it and lets the virt driver take priority.
However, with change I6a706ec5966cdc85f97223617662fe15d3e6dc08,
any virt driver that implements the update_provider_tree() interface
is storing the inventory data on the ProviderTree object which gets
cached and re-used, meaning once allocation_ratio/reserved is set
from RT._normalize_inventory_from_cn_obj, it doesn't get unset and
the normalize method always assumes the driver provided a value which
should not be changed, even if the configuration value changes.
We can make the config option changes take effect by changing
the semantics between _normalize_inventory_from_cn_obj and
drivers that implement the update_provider_tree interface, like
for the libvirt driver. Effectively with this change, when a driver
implements update_provider_tree(), they now control setting the
allocation_ratio and reserved resource amounts for inventory they
report. The libvirt driver will use the same configuration option
values that _normalize_inventory_from_cn_obj used. The only difference
is in update_provider_tree we don't have the ComputeNode facade to
get the "real" default values when the allocation_ratio is 0.0, so
we handle that like "CONF.cpu_allocation_ratio or 16.0". Eventually
that will get cleaned up with blueprint initial-allocation-ratios.
Change-Id: I72c83a95dabd581998470edb9543079acb6536a5
Closes-Bug: #1799727
ca279c68a5