f49ec409fd
In https://blueprints.launchpad.net/nova/+spec/cells-count-resources-to-check-quota-in-api we introduced a new workflow of Quota checks. It is possible that concurrent requests can pass API layer checks, but blocked by conductor layer checks. This can actually trigger user-noticeable API behavior changes: As an user, previously, If my request is blocked by quota checks, I will get HTTP 403 response, and no instance records will be left. After the above mentioned change, it is possible that when my requests failed at conductor layer Quota check and I got an instance in ERROR state. And in an busy cloud, users may got a lot of ERROR instances according to this and the instance number may beyond the limit. We should at least mention this behavior change in the release note. Change-Id: I05606fffab4e24fc55465067b66c6a035a787d1e Related-Bug: #1716706
13 lines
630 B
YAML
13 lines
630 B
YAML
---
|
|
issues:
|
|
- In 16.0.0 Pike release, quota limits are checked in a new
|
|
fashion after change 5c90b25e49d47deb7dc6695333d9d5e46efe8665
|
|
and a new config option ``[quota]/recheck_quota`` has been
|
|
added in change eab1d4b5cc6dd424c5c7dfd9989383a8e716cae5 to
|
|
recheck quota after resource creation to prevent allowing
|
|
quota to be exceeded as a result of racing requests. These
|
|
changes could lead to requests blocked by over quota resulting
|
|
in instances in the ``ERROR`` state, rather than no instance
|
|
records as before. Refer to https://bugs.launchpad.net/nova/+bug/1716706
|
|
for detailed bug report.
|