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
(cherry picked from commit f49ec409fd8fe2dc38d2978255c68850c427f94a)
Reviewed: https:/ /review. openstack. org/525511 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=43dbbf8d877 124145b277129cb b8a12a7a0e7a0d
Committed: https:/
Submitter: Zuul
Branch: stable/pike
commit 43dbbf8d8771241 45b277129cbb8a1 2a7a0e7a0d
Author: Kevin_Zheng <email address hidden>
Date: Fri Oct 27 15:35:05 2017 +0800
Mention API behavior change when over quota limit
In /blueprints. launchpad. net/nova/ +spec/cells- count-resources -to-check- quota-in- api
https:/
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: I05606fffab4e24 fc55465067b66c6 a035a787d1e c38d2978255c688 50c427f94a)
Related-Bug: #1716706
(cherry picked from commit f49ec409fd8fe2d