Remove deprecated Core/Ram/DiskFilter

These were deprecated during Stein [1] and can now be removed, lest they
cause hassle with the PCPU work. As noted in [1], the aggregate
equivalents of same are left untouched for now.

[1] https://review.opendev.org/#/c/596502/

Change-Id: I8a0d332877fbb9794700081e7954f2501b7e7c09
Signed-off-by: Stephen Finucane <[email protected]>

Author: stephenfin

api-ref/source/parameters.yaml

@@ -2378,14 +2378,16 @@ disabled_reason_body:
 disk_available_least:
   description: |
     The actual free disk on this hypervisor(in GiB). If allocation ratios used
-    for overcommit are configured, this may be negative.
+    for overcommit are configured, this may be negative. This is intentional as
+    it provides insight into the amount by which the disk is overcommitted.
   in: body
   required: true
   type: integer
 disk_available_least_total:
   description: |
     The actual free disk on all hypervisors(in GiB). If allocation ratios used
-    for overcommit are configured, this may be negative.
+    for overcommit are configured, this may be negative. This is intentional as
+    it provides insight into the amount by which the disk is overcommitted.
   in: body
   required: true
   type: integer

doc/source/admin/configuration/schedulers.rst

@@ -156,7 +156,7 @@ Filters host by CPU core numbers with a per-aggregate ``cpu_allocation_ratio``
 value. If the per-aggregate value is not found, the value falls back to the
 global setting.  If the host is in more than one aggregate and more than one
 value is found, the minimum value will be used.  For information about how to
-use this filter, see :ref:`host-aggregates`. See also :ref:`CoreFilter`.
+use this filter, see :ref:`host-aggregates`.
 
 Note the ``cpu_allocation_ratio`` :ref:`bug 1804125 <bug-1804125>` restriction.
 
@@ -167,7 +167,7 @@ Filters host by disk allocation with a per-aggregate ``disk_allocation_ratio``
 value. If the per-aggregate value is not found, the value falls back to the
 global setting.  If the host is in more than one aggregate and more than one
 value is found, the minimum value will be used.  For information about how to
-use this filter, see :ref:`host-aggregates`. See also :ref:`DiskFilter`.
+use this filter, see :ref:`host-aggregates`.
 
 Note the ``disk_allocation_ratio`` :ref:`bug 1804125 <bug-1804125>`
 restriction.
@@ -302,7 +302,7 @@ Filters host by RAM allocation of instances with a per-aggregate
 value falls back to the global setting.  If the host is in more than one
 aggregate and thus more than one value is found, the minimum value will be
 used.  For information about how to use this filter, see
-:ref:`host-aggregates`.  See also :ref:`ramfilter`.
+:ref:`host-aggregates`.
 
 Note the ``ram_allocation_ratio`` :ref:`bug 1804125 <bug-1804125>` restriction.
 
@@ -364,50 +364,6 @@ Passes all hosts that are operational and enabled.
 
 In general, you should always enable this filter.
 
-.. _CoreFilter:
-
-CoreFilter
-----------
-
-.. deprecated:: 19.0.0
-
-   ``CoreFilter`` is deprecated since the 19.0.0 Stein release. VCPU
-   filtering is performed natively using the Placement service when using the
-   ``filter_scheduler`` driver. Furthermore, enabling CoreFilter may
-   incorrectly filter out `baremetal nodes`_ which must be scheduled using
-   custom resource classes.
-
-Only schedules instances on hosts if sufficient CPU cores are available.  If
-this filter is not set, the scheduler might over-provision a host based on
-cores. For example, the virtual cores running on an instance may exceed the
-physical cores.
-
-You can configure this filter to enable a fixed amount of vCPU overcommitment
-by using the ``cpu_allocation_ratio`` configuration option in ``nova.conf``.
-The default setting is:
-
-.. code-block:: ini
-
-   cpu_allocation_ratio = 16.0
-
-With this setting, if 8 vCPUs are on a node, the scheduler allows instances up
-to 128 vCPU to be run on that node.
-
-To disallow vCPU overcommitment set:
-
-.. code-block:: ini
-
-   cpu_allocation_ratio = 1.0
-
-.. note::
-
-   The Compute API always returns the actual number of CPU cores available on a
-   compute node regardless of the value of the ``cpu_allocation_ratio``
-   configuration key. As a result changes to the ``cpu_allocation_ratio`` are
-   not reflected via the command line clients or the dashboard.  Changes to
-   this configuration key are only taken into account internally in the
-   scheduler.
-
 DifferentHostFilter
 -------------------
 
@@ -442,83 +398,6 @@ With the API, use the ``os:scheduler_hints`` key. For example:
        }
    }
 
-.. _DiskFilter:
-
-DiskFilter
-----------
-
-.. deprecated:: 19.0.0
-
-   ``DiskFilter`` is deprecated since the 19.0.0 Stein release. DISK_GB
-   filtering is performed natively using the Placement service when using the
-   ``filter_scheduler`` driver. Furthermore, enabling DiskFilter may
-   incorrectly filter out `baremetal nodes`_ which must be scheduled using
-   custom resource classes.
-
-Only schedules instances on hosts if there is sufficient disk space available
-for root and ephemeral storage.
-
-You can configure this filter to enable a fixed amount of disk overcommitment
-by using the ``disk_allocation_ratio`` configuration option in the
-``nova.conf`` configuration file.  The default setting disables the possibility
-of the overcommitment and allows launching a VM only if there is a sufficient
-amount of disk space available on a host:
-
-.. code-block:: ini
-
-   disk_allocation_ratio = 1.0
-
-DiskFilter always considers the value of the ``disk_available_least`` property
-and not the one of the ``free_disk_gb`` property of a hypervisor's statistics:
-
-.. code-block:: console
-
-   $ openstack hypervisor stats show
-   +----------------------+-------+
-   | Field                | Value |
-   +----------------------+-------+
-   | count                | 1     |
-   | current_workload     | 0     |
-   | disk_available_least | 14    |
-   | free_disk_gb         | 27    |
-   | free_ram_mb          | 15374 |
-   | local_gb             | 27    |
-   | local_gb_used        | 0     |
-   | memory_mb            | 15886 |
-   | memory_mb_used       | 512   |
-   | running_vms          | 0     |
-   | vcpus                | 8     |
-   | vcpus_used           | 0     |
-   +----------------------+-------+
-
-As it can be viewed from the command output above, the amount of the available
-disk space can be less than the amount of the free disk space.  It happens
-because the ``disk_available_least`` property accounts for the virtual size
-rather than the actual size of images.  If you use an image format that is
-sparse or copy on write so that each virtual instance does not require a 1:1
-allocation of a virtual disk to a physical storage, it may be useful to allow
-the overcommitment of disk space.
-
-When disk space is overcommitted, the value of ``disk_available_least`` can
-be negative. Rather than rounding up to 0, the original negative value is
-reported, as this way a user can see the amount by which they are
-overcommitting, and the disk weigher can select a host which is less
-overcommitted than another host.
-
-To enable scheduling instances while overcommitting disk resources on the node,
-adjust the value of the ``disk_allocation_ratio`` configuration option to
-greater than ``1.0``:
-
-.. code-block:: none
-
-   disk_allocation_ratio > 1.0
-
-.. note::
-
-   If the value is set to ``>1``, we recommend keeping track of the free disk
-   space, as the value approaching ``0`` may result in the incorrect
-   functioning of instances using it at the moment.
-
 .. _ImagePropertiesFilter:
 
 ImagePropertiesFilter
@@ -709,37 +588,6 @@ PciPassthroughFilter
 The filter schedules instances on a host if the host has devices that meet the
 device requests in the ``extra_specs`` attribute for the flavor.
 
-.. _RamFilter:
-
-RamFilter
----------
-
-.. deprecated:: 19.0.0
-
-   ``RamFilter`` is deprecated since the 19.0.0 Stein release. MEMORY_MB
-   filtering is performed natively using the Placement service when using the
-   ``filter_scheduler`` driver. Furthermore, enabling RamFilter may
-   incorrectly filter out `baremetal nodes`_ which must be scheduled using
-   custom resource classes.
-
-.. _baremetal nodes: https://docs.openstack.org/ironic/latest/install/configure-nova-flavors.html
-
-Only schedules instances on hosts that have sufficient RAM available.  If this
-filter is not set, the scheduler may over provision a host based on RAM (for
-example, the RAM allocated by virtual machine instances may exceed the physical
-RAM).
-
-You can configure this filter to enable a fixed amount of RAM overcommitment by
-using the ``ram_allocation_ratio`` configuration option in ``nova.conf``. The
-default setting is:
-
-.. code-block:: ini
-
-   ram_allocation_ratio = 1.5
-
-This setting enables 1.5 GB instances to run on any compute node with 1 GB of
-free RAM.
-
 RetryFilter
 -----------
 
@@ -1436,10 +1284,6 @@ The allocation ratio configuration is used both during reporting of compute
 node `resource provider inventory`_ to the placement service and during
 scheduling.
 
-The (deprecated) `CoreFilter`_, `DiskFilter`_ and `RamFilter`_ filters will use
-the allocation ratio from the compute node directly when calculating available
-capacity on a given node during scheduling.
-
 The `AggregateCoreFilter`_, `AggregateDiskFilter`_ and `AggregateRamFilter`_
 filters allow overriding per-compute allocation ratios by setting an allocation
 ratio value using host aggregate metadata. This provides a convenient way to
@@ -1508,6 +1352,41 @@ here.
 
 .. _osc-placement: https://docs.openstack.org/osc-placement/latest/index.html
 
+.. _hypervisor-specific-considerations:
+
+Hypervisor-specific considerations
+----------------------------------
+
+Nova provides three configuration options,
+:oslo.config:option:`reserved_host_cpus`,
+:oslo.config:option:`reserved_host_memory_mb`, and
+:oslo.config:option:`reserved_host_disk_mb`, that can be used to set aside some
+number of resources that will not be consumed by an instance, whether these
+resources are overcommitted or not. Some virt drivers may benefit from the use
+of these options to account for hypervisor-specific overhead.
+
+HyperV
+    Hyper-V creates a VM memory file on the local disk when an instance starts.
+    The size of this file corresponds to the amount of RAM allocated to the
+    instance.
+
+    You should configure the
+    :oslo.config:option:`reserved_host_disk_mb` config option to
+    account for this overhead, based on the amount of memory available
+    to instances.
+
+XenAPI
+    XenServer memory overhead is proportional to the size of the VM and larger
+    flavor VMs become more efficient with respect to overhead. This overhead
+    can be calculated using the following formula::
+
+      overhead (MB) = (instance.memory * 0.00781) + (instance.vcpus * 1.5) + 3
+
+    You should configure the
+    :oslo.config:option:`reserved_host_memory_mb` config option to
+    account for this overhead, based on the size of your hosts and
+    instances.
+
 Cells considerations
 ~~~~~~~~~~~~~~~~~~~~
 

doc/source/contributor/development-environment.rst

@@ -184,11 +184,8 @@ Using fake computes for tests
 
 The number of instances supported by fake computes is not limited by physical
 constraints. It allows you to perform stress tests on a deployment with few
-resources (typically a laptop). But you must avoid using scheduler filters
-limiting the number of instances per compute (like RamFilter, DiskFilter,
-AggregateCoreFilter), otherwise they will limit the number of instances per
-compute.
-
+resources (typically a laptop). Take care to avoid using scheduler filters
+that will limit the number of instances per compute, such as ``AggregateCoreFilter``.
 
 Fake computes can also be used in multi hypervisor-type deployments in order to
 take advantage of fake and "real" computes during tests:

doc/source/user/filter-scheduler.rst

@@ -95,8 +95,6 @@ There are many standard filter classes which may be used
   use a comma. E.g., "value1,value2". All hosts are passed if no extra_specs
   are specified.
 * |ComputeFilter| - passes all hosts that are operational and enabled.
-* |CoreFilter| - DEPRECATED; filters based on CPU core utilization. It passes
-  hosts with sufficient number of CPU cores.
 * |AggregateCoreFilter| - filters hosts by CPU core number with per-aggregate
   :oslo.config:option:`cpu_allocation_ratio` setting. If no
   per-aggregate value is found, it will fall back to the global default
@@ -110,20 +108,13 @@ There are many standard filter classes which may be used
   and :oslo.config:option:`filter_scheduler.restrict_isolated_hosts_to_isolated_images`
   flags.
 * |JsonFilter| - allows simple JSON-based grammar for selecting hosts.
-* |RamFilter| - DEPRECATED; filters hosts by their RAM. Only hosts with
-  sufficient RAM to host the instance are passed.
 * |AggregateRamFilter| - filters hosts by RAM with per-aggregate
   :oslo.config:option:`ram_allocation_ratio` setting. If no per-aggregate value
   is found, it will fall back to the global default
   :oslo.config:option:`ram_allocation_ratio`.
   If more than one value is found for a host (meaning the host is in two
   different aggregates with different ratio settings), the minimum value
   will be used.
-* |DiskFilter| - DEPRECATED; filters hosts by their disk allocation. Only
-  hosts with sufficient disk space to host the instance are passed.
-  :oslo.config:option:`disk_allocation_ratio` setting. The virtual disk to
-  physical disk allocation ratio, 1.0 by default. The total allowed allocated
-  disk size will be physical disk multiplied this ratio.
 * |AggregateDiskFilter| - filters hosts by disk allocation with per-aggregate
   :oslo.config:option:`disk_allocation_ratio` setting. If no per-aggregate value
   is found, it will fall back to the global default
@@ -356,8 +347,8 @@ of :oslo.config:option:`filter_scheduler.enabled_filters` affects scheduling
 performance. The general suggestion is to filter out invalid hosts as soon as
 possible to avoid unnecessary costs. We can sort
 :oslo.config:option:`filter_scheduler.enabled_filters`
-items by their costs in reverse order. For example, ComputeFilter is better
-before any resource calculating filters like RamFilter, CoreFilter.
+items by their costs in reverse order. For example, ``ComputeFilter`` is better
+before any resource calculating filters like ``NUMATopologyFilter``.
 
 In medium/large environments having AvailabilityZoneFilter before any
 capability or resource calculating filters can be useful.
@@ -389,15 +380,15 @@ settings:
     --scheduler.driver=nova.scheduler.FilterScheduler
     --filter_scheduler.available_filters=nova.scheduler.filters.all_filters
     --filter_scheduler.available_filters=myfilter.MyFilter
-    --filter_scheduler.enabled_filters=RamFilter,ComputeFilter,MyFilter
+    --filter_scheduler.enabled_filters=ComputeFilter,MyFilter
 
 .. note:: When writing your own filter, be sure to add it to the list of available filters
    and enable it in the default filters. The "all_filters" setting  only includes the
    filters shipped with nova.
 
 With these settings, nova will use the ``FilterScheduler`` for the scheduler
 driver. All of the standard nova filters and MyFilter are available to the
-FilterScheduler, but just the RamFilter, ComputeFilter, and MyFilter will be
+FilterScheduler, but just the ``ComputeFilter`` and ``MyFilter`` will be
 used on each request.
 
 Weights
@@ -558,13 +549,10 @@ in :mod:`nova.tests.scheduler`.
 .. |BaseHostFilter| replace:: :class:`BaseHostFilter <nova.scheduler.filters.BaseHostFilter>`
 .. |ComputeCapabilitiesFilter| replace:: :class:`ComputeCapabilitiesFilter <nova.scheduler.filters.compute_capabilities_filter.ComputeCapabilitiesFilter>`
 .. |ComputeFilter| replace:: :class:`ComputeFilter <nova.scheduler.filters.compute_filter.ComputeFilter>`
-.. |CoreFilter| replace:: :class:`CoreFilter <nova.scheduler.filters.core_filter.CoreFilter>`
 .. |AggregateCoreFilter| replace:: :class:`AggregateCoreFilter <nova.scheduler.filters.core_filter.AggregateCoreFilter>`
 .. |IsolatedHostsFilter| replace:: :class:`IsolatedHostsFilter <nova.scheduler.filters.isolated_hosts_filter>`
 .. |JsonFilter| replace:: :class:`JsonFilter <nova.scheduler.filters.json_filter.JsonFilter>`
-.. |RamFilter| replace:: :class:`RamFilter <nova.scheduler.filters.ram_filter.RamFilter>`
 .. |AggregateRamFilter| replace:: :class:`AggregateRamFilter <nova.scheduler.filters.ram_filter.AggregateRamFilter>`
-.. |DiskFilter| replace:: :class:`DiskFilter <nova.scheduler.filters.disk_filter.DiskFilter>`
 .. |AggregateDiskFilter| replace:: :class:`AggregateDiskFilter <nova.scheduler.filters.disk_filter.AggregateDiskFilter>`
 .. |NumInstancesFilter| replace:: :class:`NumInstancesFilter <nova.scheduler.filters.num_instances_filter.NumInstancesFilter>`
 .. |AggregateNumInstancesFilter| replace:: :class:`AggregateNumInstancesFilter <nova.scheduler.filters.num_instances_filter.AggregateNumInstancesFilter>`