commit ca279c68a54b054cb54d45ee9d2eed8ade9a6db5
Author: Matt Riedemann <email address hidden>
Date: Wed Oct 24 13:48:06 2018 -0400
Provide allocation_ratio/reserved amounts from update_provider_tree()
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.
Reviewed: https:/ /review. openstack. org/613126 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=ca279c68a54 b054cb54d45ee9d 2eed8ade9a6db5
Committed: https:/
Submitter: Zuul
Branch: master
commit ca279c68a54b054 cb54d45ee9d2eed 8ade9a6db5
Author: Matt Riedemann <email address hidden>
Date: Wed Oct 24 13:48:06 2018 -0400
Provide allocation_ ratio/reserved amounts from update_ provider_ tree()
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 I6a706ec5966cdc 85f97223617662f e15d3e6dc08, provider_ tree() interface ratio/reserved is set inventory_ from_cn_ obj, it doesn't get unset and
any virt driver that implements the update_
is storing the inventory data on the ProviderTree object which gets
cached and re-used, meaning once allocation_
from RT._normalize_
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 inventory_ from_cn_ obj and provider_ tree interface, like provider_ tree(), they now control setting the ratio and reserved resource amounts for inventory they inventory_ from_cn_ obj used. The only difference provider_ tree we don't have the ComputeNode facade to allocation_ ratio or 16.0". Eventually allocation- ratios.
the semantics between _normalize_
drivers that implement the update_
for the libvirt driver. Effectively with this change, when a driver
implements update_
allocation_
report. The libvirt driver will use the same configuration option
values that _normalize_
is in update_
get the "real" default values when the allocation_ratio is 0.0, so
we handle that like "CONF.cpu_
that will get cleaned up with blueprint initial-
Change-Id: I72c83a95dabd58 1998470edb95430 79acb6536a5
Closes-Bug: #1799727