Open Stack

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>