Filter Scheduler in nova documents include obsolete filters

Bug #1852511 reported by Albert Braden
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Triaged
Medium
Unassigned

Bug Description

This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes:

- [X] This doc is inaccurate in this way:
RetryFilter was deprecated in Queens
RamFilter and CoreFilter were deprecated in Pike

There may be others; I'm not sure I have the complete list of deprecated filters. Will you please remove the deprecated filters from the Rocky documents, or else change the document to specify that they are deprecated?

- [ ] This is a doc addition request.
- [X] I have a fix to the document that I can paste below including example: input and output.

Change: CoreFilter - filters based on CPU core utilization. It passes hosts with sufficient number of CPU cores.
To: CoreFilter - Deprecated since Pike; please do not use.

Change: RamFilter - filters hosts by their RAM. Only hosts with sufficient RAM to host the instance are passed.
To: RamFilter - Deprecated since Pike; please do not use.

Change: RetryFilter - filters hosts that have been attempted for scheduling. Only passes hosts that have not been previously attempted.
To: RetryFilter - Deprecated since Queens; please do not use

If you have a troubleshooting or support issue, use the following resources:

 - Ask OpenStack: http://ask.openstack.org
 - The mailing list: http://lists.openstack.org
 - IRC: 'openstack' channel on Freenode

-----------------------------------
Release: 18.2.4.dev20 on 2019-11-04 20:25
SHA: a90fe1951200ebd27fe74788c0a96c01104ac2cf
Source: https://git.openstack.org/cgit/openstack/nova/tree/doc/source/user/filter-scheduler.rst
URL: https://docs.openstack.org/nova/rocky/user/filter-scheduler.html

Tags: doc scheduler
Revision history for this message
Albert Braden (ozzzo) wrote :
Revision history for this message
Matt Riedemann (mriedem) wrote :

The docs in Rocky don't mention the Core/Ram/Disk filters as being deprecated because they weren't formally deprecated until the Stein release:

https://review.opendev.org/#/c/596502/

Anyone using the CachingScheduler scheduler driver in Rocky would still want to be using the Core/Ram/Disk filters since the CachingScheduler driver doesn't use placement.

Similarly, the RetryFilter wasn't deprecated until Train:

https://review.opendev.org/#/c/663953/

So I'm not sure what to say in Rocky-specific release notes. We could have separate changes, one for RetryFilter (start in stable/stein and backport to stable/rocky) which says it's no longer useful and one for stable/rocky that says core/ram/disk filters are not necessary when using the FilterScheduler scheduler driver (not CachingScheduler driver). My point is these would be stable branch specific docs patches that don't mention deprecation since the filters were not formally deprecated in those older releases.

Changed in nova:
status: New → Triaged
importance: Undecided → Medium
tags: added: scheduler
Revision history for this message
Albert Braden (ozzzo) wrote :

We experienced scheduling issues in our 200-node cluster, and those issues were resolved by removing the obsolete filters. See the thread starting with http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010727.html for details.

Revision history for this message
Matt Riedemann (mriedem) wrote :

Heh, yeah I'm aware of the thread, and thanks for opening a bug for this. I'm just trying to figure out what we'd put in the docs since before we dropped the CachingScheduler driver the Core/Ram/Disk filters were valid even if deprecated. We could probably just put a note in the docs like that, e.g. this filter may cause issues if you're using the (default) FilterScheduler driver.

Revision history for this message
Albert Braden (ozzzo) wrote :

Maybe something like "These filters are not officially deprecated in Rocky but are known to cause trouble in large deployments."

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.