Open Stack

 ---- On Thu, 28 Nov 2019 03:02:19 -0600 Alex Xu <soulxu at gmail.com> wrote ----
 > 
 > 
 > Ghanshyam Mann <gmann at ghanshyammann.com> 于2019年11月28日周四 上午2:27写道：
 >  ---- On Wed, 27 Nov 2019 03:35:43 -0600 Surya Seetharaman <surya.seetharaman9 at gmail.com> wrote ----
 >  > 
 >  > 
 >  > On Tue, Nov 26, 2019 at 9:26 PM Matt Riedemann <mriedemos at gmail.com> wrote:
 >  > 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).
 >  > 
 >  > 
 >  > 
 >  > 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.
 > 
 > +1 on the solution. I like that code tells the error to users because people do not read the doc always. 
 > 
 >  >  
 >  > I don't think a microversion is necessary for this 
 >  > ++
 > 
 > I disagree here.  My main concern is that this is not the always-broken case.
 > For the case where we have complete broken behaviour then we do not need microverison to fix that as mentioned by matt too.
 > 
 >  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
 > 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).
 > This is behaviour change and should be done with microvesion.
 > 
 > 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. 

yeah, they can fix it via configuration change only so we can consider this as policy default change or extra policy checks changes which do not require microversion.

-gmann

 > 
 > 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.
 > which was clearly a broken case. Any other case where projects may exist was kept as it is so microversion was not needed there. 
 > 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
 > nova cannot process the request. Your project might be valid but nova cannot conform that till you have permission to GET /project.
 > 
 >  -gmann
 > 
 >  >  
 >  > ----------
 >  > 
 >  > Cheers,Surya.
 > 
 > 
 >