Comment 14 for bug 1799727

Reviewed: https://review.openstack.org/613126
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=ca279c68a54b054cb54d45ee9d2eed8ade9a6db5
Submitter: Zuul
Branch: master

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.

    Change-Id: I72c83a95dabd581998470edb9543079acb6536a5
    Closes-Bug: #1799727