[nova][api] Behaviour of project_id validation

Alex Xu soulxu at gmail.com
Thu Nov 28 09:02:19 UTC 2019

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.

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191128/71ec397e/attachment.html>

More information about the openstack-discuss mailing list