<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Ghanshyam Mann <<a href="mailto:gmann@ghanshyammann.com">gmann@ghanshyammann.com</a>> 于2019年11月28日周四 上午2:27写道:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> ---- On Wed, 27 Nov 2019 03:35:43 -0600 Surya Seetharaman <<a href="mailto:surya.seetharaman9@gmail.com" target="_blank">surya.seetharaman9@gmail.com</a>> wrote ----<br>
 > <br>
 > <br>
 > On Tue, Nov 26, 2019 at 9:26 PM Matt Riedemann <<a href="mailto:mriedemos@gmail.com" target="_blank">mriedemos@gmail.com</a>> wrote:<br>
 > Note that the APIs that would change are admin-only by default. So in <br>
 > this case nova is configured with a service user to check if the <br>
 > requested project_id exists on behalf of the (admin) user making the <br>
 > compute API request to add/remove flavor access (or update quota values <br>
 > for a project). The service user does not have enough permissions in <br>
 > keystone to check if the project exists. Option 1 is give that service <br>
 > user more authority. Option 2 is basically re-raise that error to the <br>
 > compute (admin) user to let them know they basically need to fix their <br>
 > deployment (option 1 again).<br>
 > <br>
 > <br>
 > <br>
 > A combo of both solutions where we raise the error to the user and amend our docs to help them fix it seems good to me.<br>
<br>
+1 on the solution. I like that code tells the error to users because people do not read the doc always. <br>
<br>
 >  <br>
 > I don't think a microversion is necessary for this <br>
 > ++<br>
<br>
I disagree here.  My main concern is that this is not the always-broken case.<br>
For the case where we have complete broken behaviour then we do not need microverison to fix that as mentioned by matt too.<br>
<br>
 In this case: Even 403 from keystone on GET /project, it may possible that the project exists and request Nova to add that projects in<br>
flavor access is right. This is a success case in the current situation which will be changed to 400 after the proposed solution(option2 or 2+1).<br>
This is behaviour change and should be done with microvesion.<br></blockquote><div><br></div><div>That is the case we expected to be fixed by the operator, right? If the operator fix that, then there won't be any API behavior change. I guess that what Matt point.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In old change where we added the verify_project_id did not change the success case, that only handled the case where keystone returned<br>
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.<br>
which was clearly a broken case. Any other case where projects may exist was kept as it is so microversion was not needed there. <br>
But now we are changing the success cases also to return an error and ask the user to have the GET /project permission first otherwise<br>
nova cannot process the request. Your project might be valid but nova cannot conform that till you have permission to GET /project.<br>
<br>
 -gmann<br>
<br>
 >  <br>
 > ----------<br>
 > <br>
 > Cheers,Surya.<br>
<br>
<br>
</blockquote></div></div>