Merge "Remove deprecated AZ filter."

doc/source/admin/availability-zones.rst

@@ -69,10 +69,9 @@ Availability Zones with Placement
 
 In order to use placement to honor availability zone requests, there must be
 placement aggregates that match the membership and UUID of nova host aggregates
-that you assign as availability zones. The same key in aggregate metadata used
-by the `AvailabilityZoneFilter` filter controls this function, and is enabled by
-setting :oslo.config:option:`scheduler.query_placement_for_availability_zone`
-to ``True``. As of 24.0.0 (Xena), this is the default.
+that you assign as availability zones. An aggregate metadata key is used
+to controls this function. As of 28.0.0 (Bobcat), this is the only way to
+schedule instances to availability-zones.
 
 .. code-block:: console
 
@@ -107,12 +106,6 @@ to ``True``. As of 24.0.0 (Xena), this is the default.
 
   $ openstack aggregate set --property availability_zone=az002 myaz
 
-  $ openstack --os-placement-api-version=1.2 resource provider aggregate set --aggregate 019e2189-31b3-49e1-aff2-b220ebd91c24 815a5634-86fb-4e1e-8824-8a631fee3e06
-
-Without the above configuration, the `AvailabilityZoneFilter` filter must be
-enabled in :oslo.config:option:`filter_scheduler.enabled_filters` to retain
-proper behavior.
-
 Implications for moving servers
 -------------------------------
 
@@ -183,8 +176,7 @@ With respect to availability zones, a server is restricted to a zone if:
    for details.
 
 If the server was not created in a specific zone then it is free to be moved
-to other zones, i.e. the :ref:`AvailabilityZoneFilter <AvailabilityZoneFilter>`
-is a no-op.
+to other zones.
 
 Resource affinity
 ~~~~~~~~~~~~~~~~~

doc/source/admin/scheduling.rst

@@ -10,7 +10,8 @@ a variety of options.
 In the default configuration, this scheduler considers hosts that meet all the
 following criteria:
 
-* Are in the requested :term:`Availability Zone` (``AvailabilityZoneFilter``).
+* Are in the requested :term:`Availability Zone`
+  (``map_az_to_placement_aggregate``) placement pre filter.
 
 * Can service the request meaning the nova-compute service handling the target
   node is available and not disabled (``ComputeFilter``).
@@ -166,9 +167,6 @@ possible to avoid unnecessary costs. We can sort
 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.
-
 .. _AggregateImagePropertiesIsolation:
 
 ``AggregateImagePropertiesIsolation``
@@ -349,20 +347,6 @@ Refer to :doc:`/admin/aggregates` for more information.
 This is a no-op filter. It does not eliminate any of the available hosts.
 
 
-.. _AvailabilityZoneFilter:
-
-``AvailabilityZoneFilter``
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Filters hosts by availability zone. It passes hosts matching the availability
-zone specified in the instance properties.  Use a comma to specify multiple
-zones. The filter will then ensure it matches any zone specified.
-
-You must enable this filter for the scheduler to respect availability zones in
-requests.
-
-Refer to :doc:`/admin/availability-zones` for more information.
-
 .. _ComputeCapabilitiesFilter:
 
 ``ComputeCapabilitiesFilter``

doc/source/contributor/testing/libvirt-numa.rst

@@ -134,7 +134,7 @@ For example:
 
   [[post-config|$NOVA_CONF]]
   [filter_scheduler]
-  enabled_filters=ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter,NUMATopologyFilter
+  enabled_filters=ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter,NUMATopologyFilter
   EOF
   $ FORCE=yes ./stack.sh