[openstack-dev] [nova] The status of servers API's filters

Alex Xu soulxu at gmail.com
Sun Jan 29 01:12:41 UTC 2017


2017-01-29 1:31 GMT+08:00 Matt Riedemann <mriedemos at gmail.com>:

> On 1/27/2017 3:37 AM, Alex Xu wrote:
>
>> The patches about validation the filters and sorts for servers API are
>> merged [0]. But we still have something left [1].
>>
>> The left is about the proposal of introducing the new rule
>> 'os_compute_api:servers:all_tenants_visible' which is soft enforcement.
>> The new rule will instead of the old hard enforcement rule
>> "os_compute_api:servers:index:get_all_tenants".
>>
>> In the discussion of nova API meeting, Join pointed out that the change
>> from hard enforcement to soft enforcement needs Microversion. The API
>> used to return 403 when user didn't have permission of all_tenants
>> parameter. But now the API returns 200 with the own instances when no
>> permission of all_tenants parameter. So the proposal should be separated
>> to two parts:
>>
>> i. rename the policy from "get_all_tenants" to the "all_tenants_visible"
>> ii. change the enforcement from hard to soft by Microversion.
>>
>> In the old microversion, the rule keeps as hard enforcement.
>>
>> So in Ocata, "get_all_tenants" will be deprecated. If the deployer have
>> overriden rule in the policy file, the old rule still will be enforced,
>> and the warning message will be emit to notice that the user needs to
>> move their custom rule to the new rule 'all_tenants_visiable'. And if
>> the API user requests with new microversion, the rule will become soft
>> enforcement.
>>
>> So if that sounds make sense, there also have another question about
>> whether we have enough time to merge it. I think Matt will make a call
>> on it.
>>
>> And due to holidays in China, both I and Kevin are in vacation.  And
>> really really appreciate Ghanshyam take care on those patches! The
>> spec[3] and the patch[1] already updated by him.
>>
>> Anyway....Happy Chinese New Year to everyone(yea, new year again \o/).
>>
>> Thanks
>> Alex
>>
>> [0] https://review.openstack.org/408571
>> <https://review.openstack.org/408571>
>> and https://review.openstack.org/415142
>> <https://review.openstack.org/415142>
>> [1] https://review.openstack.org/#/q/status:open+project:opensta
>> ck/nova+branch:master+topic:bp/add-whitelist-for-server-
>> list-filter-sort-parameters
>> <https://review.openstack.org/#/q/status:open+project:openst
>> ack/nova+branch:master+topic:bp/add-whitelist-for-server-
>> list-filter-sort-parameters>
>> [3] https://review.openstack.org/425533
>> <https://review.openstack.org/425533>
>>
>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> My immediate question is, does this need to happen in Ocata or can we
> defer the all_tenants_visible policy change to Pike? Is there anything we
> merged in Ocata that is now broken, or weird, or blocks us from doing
> something later, etc if we don't get this done now?
>

I didn't see any broken or blocks without the all_tenants_visiable policy
change. The policy change is just part of vision of how filters should be
looks like between admin user and non-admin user.


>
> Honestly I never really understood why the all_tenants policy change was
> being lumped in with the server sort/filter whitelist blueprint, except
> maybe just because of convenience?
>

Emm..I didn't remember any discussion about why we should put all of them
into one spec or not.


> Anyway, this seems like something we can defer to Pike unless I'm missing
> something.


I'm ok with that, due to I didn't have any critical reason. The only thing
is we need one more cycle to remove a old policy rule. But currently the
new proposal without more discussion, and we only have 1 week left for spec
change and patches. It isn't worth to take that risk I guess.

Anyway, Matt, thanks for your response.


>
>
> --
>
> Thanks,
>
> Matt Riedemann
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170129/be5c8578/attachment.html>


More information about the OpenStack-dev mailing list