Open Stack

I'd recommend adding a subject title in the future.

On 11/26/2019 12:08 PM, Surya Seetharaman wrote:
> 2) change the 403 case as an error and raise it back to the compute api 
> caller - maybe enough time has passed to not worry about backward compat 
> with the old non-validating behavior

Note that the APIs that would change are admin-only by default. So in 
this case nova is configured with a service user to check if the 
requested project_id exists on behalf of the (admin) user making the 
compute API request to add/remove flavor access (or update quota values 
for a project). The service user does not have enough permissions in 
keystone to check if the project exists. Option 1 is give that service 
user more authority. Option 2 is basically re-raise that error to the 
compute (admin) user to let them know they basically need to fix their 
deployment (option 1 again).

> 
> Option 2 seems better than option 1 for most of us, however what we 
> cannot agree upon is if this change should be accompanied by a 
> microversion bump or not.

As noted above, I don't think option 2 precludes option 1. The compute 
API (admin) user will just get a 403 rather than perhaps silently wrong 
200 response. If they get a 403 they likely need to fix things which is 
option 1.

I don't think a microversion is necessary for this if we go with option 
2 since the admin user shouldn't have to opt into non-broken behavior. 
Yes the project_id validation stuff was added awhile ago but it was 
added without a microversion in its own right as a bug fix - and we used 
to get a *lot* of duplicate bugs about being able to use these APIs with 
garbage project IDs since we previously didn't validate. Here are a 
couple of other examples of (non-admin) APIs which changed from a bogus 
success response to a failure without a microversion:

* Trying to attach an SR-IOV port to an instance.
* Trying to rebuild a volume-backed server with a new image.

-- 

Thanks,

Matt