2017-01-29 1:31 GMT+08:00 Matt Riedemann <mriede...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
