[nova][api] Behaviour of project_id validation
mriedemos at gmail.com
Thu Nov 28 14:34:03 UTC 2019
On 11/27/2019 12:26 PM, Ghanshyam Mann wrote:
> In old change where we added the verify_project_id did not change the success case, that only handled the case where keystone returned
> 404 on GET /project means it is confirmed that the requested project does not exist so it will break later so nova started 400 instead of 200.
What "old change" are you referring to here? Before  there was *no*
validation performed when adding/removing flavor access or updating
quotas for a given project. Hence all of the duplicate bugs about being
able to typo/fat-finger/pass garbage values to those APIs and then be
confused later when flavor access and quotas aren't working as expected.
There have been a few changes to the verify method since it was added,
but the point is it was a non-microversion change to admin APIs which
would turn previously invalid but passing requests to failures.
I'm assuming 403 was handled "gracefully" more for backward
compatibility than anything else but as can be seen from Surya's bug is
just masking the original issue that this validation code was trying to fix.
Nothing is changing in request or response schema and this should only
be enforced (re-raise on 403 from keystone) in the APIs that are
admin-only by default so it's not an interop concern.
I just don't see why we would expect someone to need to opt into this
validation actually working - and if misconfigured actually failing to
indicate to the admin using the API that their deployment needs to be fixed.
More information about the openstack-discuss