From 18c40cacc13d76bf8199d61cac6ecc2af3122c8f Mon Sep 17 00:00:00 2001 From: Matt Riedemann Date: Fri, 15 Mar 2019 11:39:33 -0400 Subject: [PATCH] Remove stale aggregates notes from scheduler evolution doc Since I901184cb1a4b6eb0d6fa6363bc6ffbcaa0c9d21d in Kilo the aggregates information about a HostState object (which is a wrapper over a ComputeNode) is cached in the scheduler, so the comments in the scheduler evolution doc about not accessing the aggregates table in the DB from filters/weighers and such is extremely out of date and should just be removed. Change-Id: Ibcbad227813d3b37b4e314eddbf3bae6e85652ea Related-Bug: #1820283 --- doc/source/reference/scheduler-evolution.rst | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/doc/source/reference/scheduler-evolution.rst b/doc/source/reference/scheduler-evolution.rst index 43f1ffd5ba38..8207d31faa97 100644 --- a/doc/source/reference/scheduler-evolution.rst +++ b/doc/source/reference/scheduler-evolution.rst @@ -43,14 +43,6 @@ that is close to the shared storage where that volume is. Similarly, for the sake of performance, it can be desirable to use a compute node that is in a particular location in relation to a pre-created port. -Accessing Aggregates in Filters and Weights --------------------------------------------- - -Any DB access in a filter or weight slows down the scheduler. Until the -end of kilo, there was no way to deal with the scheduler accessing -information about aggregates without querying the DB in every call to -host_passes() in a filter. - Filter Scheduler Alternatives ------------------------------ @@ -91,10 +83,6 @@ pluggable through the service group API, and should be independent of the scheduler service. For example, it could be managed via zookeeper rather than polling the nova DB. -There are also places where filters and weights call into the nova DB to -find out information about aggregates. This needs to be sent to the -scheduler, rather than reading directly from the nova database. - Versioning Scheduler Placement Interfaces ------------------------------------------ @@ -124,9 +112,6 @@ This is linked to the work on the resource tracker. Updating the Scheduler about other data ---------------------------------------- -For things like host aggregates, we need the scheduler to cache information -about those, and know when there are changes so it can update its cache. - Over time, its possible that we need to send cinder and neutron data, so the scheduler can use that data to help pick a nova-compute host.