openstack/nova-specs
Code Issues Proposed changes

Record reality of placement API usage from n-sched

Browse Source 
The resource-providers-scheduler-db-filters spec previously contained wording
that intimated that the scheduler would begin to use the placement API for
scheduling decisions as soon as some nova-compute workers were upgraded and
began reporting inventory and allocation records to the placement API. This is
not how Ocata was released. Instead, the placement API is only queried from the
scheduler once all nova-compute workers have been upgraded to Ocata. This patch
simply records that new reality.

Change-Id: I9b9e3855b8479dd22d714149889793224909832f
This commit is contained in:
Jay Pipes
2017-02-10 14:58:31 -05:00
parent e178c2bb59
commit 3c48c2295b
1 changed files with 15 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
specs/ocata/approved/resource-providers-scheduler-db-filters.rst
View File

@@ -131,29 +131,25 @@ Keystone so that the nova-computes could find the placement API.
In Ocata, the placement service is required, however we will build a sort of
self-healing process into the new behaviour of the scheduler calling to the
placement API to winnow the set of compute hosts that are acted upon. If the
placement service has been set up and the deployer upgrades her control plane
to Ocata and restarts her nova-scheduler services, the new Ocata scheduler will
attempt to contact the placement service to get a list of resource providers
(compute hosts) that meet a set of requested resource amounts.
placement service has been set up but all nova-computes have yet to be upgraded
to Ocata, the scheduler will continue to use its existing behaviour of querying
the Nova cell database compute_nodes table. Once all nova-compute workers have
been upgraded to Ocata, the new Ocata scheduler will attempt to contact the
placement service to get a list of resource providers (compute hosts) that meet
a set of requested resource amounts.
Initially, since no nova-computes had successfully run through their periodic
audit interval, the placement database would be empty and thus the request from
the scheduler to the placement API for resource providers would return an empty
list. We will place code into the scheduler that, upon seeing an empty list of
resource providers returned from the placement API, will fall back to the
legacy behaviour of calling ComputeNodeList.get_all(). This will allow the old
scheduler behaviour to take over in between the time when the new placement
service is brought online and when nova-compute nodes are restarted (triggering
a fresh call out to the placement service, which can now be contacted, and
populating the placement DB with records).
In the scenario of a freshly-upgraded Ocata deployment that previously had not
had the placement service established (and thus no nova-computes had
successfully written records to the placement database), the scheduler may
momentarily return a NoValidHosts while the placement database is populated.
As restarts (or upgrades+restarts) of the nova-computes are rolled out, the
placement database will begin to fill up with allocation and inventory
information. There may be a short period of time while the scheduler receives a
smaller-than-accurate set of resource providers that meet the requested
resource amounts. This may result in a few retry events but under no
circumstances should there be a NoValidHost returned since the scheduler will
fall back to its old ComputeNodeList.get_all() behaviour.
information. Please note that the scheduler will not use the placement API for
decisions until **all** nova-compute workers have been upgraded to Ocata. There
is a check for service version in the scheduler that requires all nova-computes
in the deployment to be upgraded to Ocata before the scheduler will begin using
the placement API for scheduling decisions.
Developer impact
----------------