Open Stack

On Sun, Jan 29, 2017 at 10:12 AM, Alex Xu <soulxu at gmail.com> wrote:

>
>
> 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-lis
>>> t-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.op
>>> enstack.org?subject:unsubscribe
>>> 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.
>

​Ok, I was thinking if we could get new policy and old policy deprecation​
in Ocata and behavior change in Pike but yes that needs spec update and
review which is little bit tight for Ocata.

I am also ok to defer this in Pike.



>
> 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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> 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/20170130/3bc79f40/attachment.html>