Hm, I found out the reason: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L1139-L1145 here we filtered out parameters like "deleted", and that's why the API behavior is like above mentioned.
So should we simple add "deleted" to the tuple or a microversion is needed? On Fri, Mar 4, 2016 at 10:27 AM, Zhenyu Zheng <zhengzhenyul...@gmail.com> wrote: > Anyway, I updated the bug report: > https://bugs.launchpad.net/nova/+bug/1552071 > > and I will start to working on the bug first. > > On Fri, Mar 4, 2016 at 9:29 AM, Zhenyu Zheng <zhengzhenyul...@gmail.com> > wrote: > >> Yes, so you are suggest fixing the return data of non-admin user use >> 'nova list --deleted' but leave non-admin using 'nova list >> --status=deleted' as is. Or it would be better to also submit a BP for next >> cycle to add support for non-admin using '--status=deleted' with >> microversions. Because in my opinion, if we allow non-admin use "nova list >> --deleted", there will be no reason for us to limit the use of >> "--status=deleted". >> >> On Fri, Mar 4, 2016 at 12:37 AM, Matt Riedemann < >> mrie...@linux.vnet.ibm.com> wrote: >> >>> >>> >>> On 3/3/2016 10:02 AM, Matt Riedemann wrote: >>> >>>> >>>> >>>> On 3/3/2016 2:55 AM, Zhenyu Zheng wrote: >>>> >>>>> Yes, I agree with you guys, I'm also OK for non-admin users to list >>>>> their own instances no matter what status they are. >>>>> >>>>> My question is this: >>>>> I have done some tests, yet we have 2 different ways to list deleted >>>>> instances (not counting using changes-since): >>>>> >>>>> 1. >>>>> "GET >>>>> /v2.1/62bfb653eb0d4d5cabdf635dd8181313/servers/detail?status=deleted >>>>> HTTP/1.1" >>>>> (nova list --status deleted in CLI) >>>>> 2. REQ: curl -g -i -X GET >>>>> >>>>> http://10.229.45.17:8774/v2.1/62bfb653eb0d4d5cabdf635dd8181313/servers/detail?deleted=True >>>>> (nova >>>>> list --deleted in CLI) >>>>> >>>>> for admin user, we can all get deleted instances(after the fix of >>>>> Matt's >>>>> patch). >>>>> >>>>> But for non-admin users, #1 is restricted here: >>>>> >>>>> https://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/servers.py#n350 >>>>> >>>>> and it will return 403 error: >>>>> RESP BODY: {"forbidden": {"message": "Only administrators may list >>>>> deleted instances", "code": 403}} >>>>> >>>> >>>> This is part of the API so if we were going to allow non-admins to query >>>> for deleted servers using status=deleted, it would have to be a >>>> microversion change. [1] I could also see that being policy-driven. >>>> >>>> It does seem odd and inconsistent though that non-admins can't query >>>> with status=deleted but they can query with deleted=True in the query >>>> options. >>>> >>>> >>>>> and for #2 it will strangely return servers that are not in deleted >>>>> status: >>>>> >>>> >>>> This seems like a bug. I tried looking for something obvious in the code >>>> but I'm not seeing the issue, I'd suspect something down in the DB API >>>> code that's doing the filtering. >>>> >>>> >>>>> DEBUG (connectionpool:387) "GET >>>>> /v2.1/62bfb653eb0d4d5cabdf635dd8181313/servers/detail?deleted=True >>>>> HTTP/1.1" 200 3361 >>>>> DEBUG (session:235) RESP: [200] Content-Length: 3361 >>>>> X-Compute-Request-Id: req-bd073750-982a-4ef7-864a-a5db03e59a68 Vary: >>>>> X-OpenStack-Nova-API-Version Connection: keep-alive >>>>> X-Openstack-Nova-Api-Version: 2.1 Date: Thu, 03 Mar 2016 08:43:17 GMT >>>>> Content-Type: application/json >>>>> RESP BODY: {"servers": [{"status": "ACTIVE", "updated": >>>>> "2016-02-29T06:24:16Z", "hostId": >>>>> "56b12284bb4d1da6cbd066d15e17df252dac1f0dc6c81a74bf0634b7", >>>>> "addresses": >>>>> {"private": [{"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:4f:1b:32", >>>>> "version": >>>>> 4, "addr": "10.0.0.14", "OS-EXT-IPS:type": "fixed"}, >>>>> {"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:4f:1b:32", "version": 6, "addr": >>>>> "fdb7:5d7b:6dcd:0:f816:3eff:fe4f:1b32", "OS-EXT-IPS:type": "fixed"}]}, >>>>> "links": [{"href": >>>>> " >>>>> http://10.229.45.17:8774/v2.1/62bfb653eb0d4d5cabdf635dd8181313/servers/ee8907c7-0730-4051-8426-64be44300e70 >>>>> ", >>>>> >>>>> "rel": "self"}, {"href": >>>>> " >>>>> http://10.229.45.17:8774/62bfb653eb0d4d5cabdf635dd8181313/servers/ee8907c7-0730-4051-8426-64be44300e70 >>>>> ", >>>>> >>>>> "rel": "bookmark"}], "key_name": null, "image": {"id": >>>>> "6455625c-a68d-4bd3-ac2e-07382ac5cbf4", "links": [{"href": >>>>> " >>>>> http://10.229.45.17:8774/62bfb653eb0d4d5cabdf635dd8181313/images/6455625c-a68d-4bd3-ac2e-07382ac5cbf4 >>>>> ", >>>>> >>>>> "rel": "bookmark"}]}, "OS-EXT-STS:task_state": null, >>>>> "OS-EXT-STS:vm_state": "active", "OS-SRV-USG:launched_at": >>>>> "2016-02-29T06:24:16.000000", "flavor": {"id": "1", "links": [{"href": >>>>> "http://10.229.45.17:8774/62bfb653eb0d4d5cabdf635dd8181313/flavors/1";, >>>>> "rel": "bookmark"}]}, "id": "ee8907c7-0730-4051-8426-64be44300e70", >>>>> "security_groups": [{"name": "default"}], "OS-SRV-USG:terminated_at": >>>>> null, "OS-EXT-AZ:availability_zone": "nova", "user_id": >>>>> "da935c024dc1444abb7b32390eac4e0b", "name": "test_inject", "created": >>>>> "2016-02-29T06:24:08Z", "tenant_id": >>>>> "62bfb653eb0d4d5cabdf635dd8181313", >>>>> "OS-DCF:diskConfig": "MANUAL", "os-extended-volumes:volumes_attached": >>>>> [], "accessIPv4": "", "accessIPv6": "", "progress": 0, >>>>> "OS-EXT-STS:power_state": 1, "config_drive": "True", "metadata": {}}, >>>>> {"status": "ACTIVE", "updated": "2016-02-29T06:21:22Z", "hostId": >>>>> "56b12284bb4d1da6cbd066d15e17df252dac1f0dc6c81a74bf0634b7", >>>>> "addresses": >>>>> {"private": [{"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:63:b0:12", >>>>> "version": >>>>> 4, "addr": "10.0.0.13", "OS-EXT-IPS:type": "fixed"}, >>>>> {"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:63:b0:12", "version": 6, "addr": >>>>> "fdb7:5d7b:6dcd:0:f816:3eff:fe63:b012", "OS-EXT-IPS:type": "fixed"}]}, >>>>> "links": [{"href": >>>>> " >>>>> http://10.229.45.17:8774/v2.1/62bfb653eb0d4d5cabdf635dd8181313/servers/40bab05f-0692-43df-a8a9-e7c0d58a73bd >>>>> ", >>>>> >>>>> "rel": "self"}, {"href": >>>>> " >>>>> http://10.229.45.17:8774/62bfb653eb0d4d5cabdf635dd8181313/servers/40bab05f-0692-43df-a8a9-e7c0d58a73bd >>>>> ", >>>>> >>>>> "rel": "bookmark"}], "key_name": null, "image": {"id": >>>>> "6455625c-a68d-4bd3-ac2e-07382ac5cbf4", "links": [{"href": >>>>> " >>>>> http://10.229.45.17:8774/62bfb653eb0d4d5cabdf635dd8181313/images/6455625c-a68d-4bd3-ac2e-07382ac5cbf4 >>>>> ", >>>>> >>>>> "rel": "bookmark"}]}, "OS-EXT-STS:task_state": null, >>>>> "OS-EXT-STS:vm_state": "active", "OS-SRV-USG:launched_at": >>>>> "2016-02-29T06:21:22.000000", "flavor": {"id": "1", "links": [{"href": >>>>> "http://10.229.45.17:8774/62bfb653eb0d4d5cabdf635dd8181313/flavors/1";, >>>>> "rel": "bookmark"}]}, "id": "40bab05f-0692-43df-a8a9-e7c0d58a73bd", >>>>> "security_groups": [{"name": "default"}], "OS-SRV-USG:terminated_at": >>>>> null, "OS-EXT-AZ:availability_zone": "nova", "user_id": >>>>> "da935c024dc1444abb7b32390eac4e0b", "name": "test_inject", "created": >>>>> "2016-02-29T06:19:51Z", "tenant_id": >>>>> "62bfb653eb0d4d5cabdf635dd8181313", >>>>> "OS-DCF:diskConfig": "MANUAL", "os-extended-volumes:volumes_attached": >>>>> [], "accessIPv4": "", "accessIPv6": "", "progress": 0, >>>>> "OS-EXT-STS:power_state": 1, "config_drive": "True", "metadata": {}}]} >>>>> >>>>> I think this is obviously not consistent, I think we can decide what >>>>> the >>>>> behavior should be and make them consistent? >>>>> >>>>> Yours, >>>>> >>>>> Kevin >>>>> >>>>> On Thu, Mar 3, 2016 at 3:59 PM, Alex Xu <sou...@gmail.com >>>>> <mailto:sou...@gmail.com>> wrote: >>>>> >>>>> >>>>> >>>>> 2016-03-03 2:11 GMT+08:00 Matt Riedemann < >>>>> mrie...@linux.vnet.ibm.com >>>>> <mailto:mrie...@linux.vnet.ibm.com>>: >>>>> >>>>> >>>>> >>>>> On 3/2/2016 3:02 AM, Zhenyu Zheng wrote: >>>>> >>>>> Hi, Nova, >>>>> >>>>> While I'm working on add "changes-since" parameter support >>>>> for >>>>> python-novaclient "list" CLI. >>>>> >>>>> I realized that non-admin can list all deleted instances >>>>> using >>>>> "changes-since" parameter. This is reasonable in some >>>>> level, >>>>> as delete >>>>> is an update to instances. But as we have a limitation that >>>>> when list >>>>> instances, deleted parameter is only allowed for admin >>>>> users. >>>>> >>>>> This will lead to inconsistent to the rule of show deleted >>>>> instances, as >>>>> we limit the list of deleted instances to admin only, but >>>>> non-admin can >>>>> get the information using changes-since. >>>>> >>>>> Should we fix this? >>>>> >>>>> https://bugs.launchpad.net/nova/+bug/1552071 >>>>> >>>>> Thanks, >>>>> >>>>> Kevin Zheng >>>>> >>>>> >>>>> >>>>> >>>>> __________________________________________________________________________ >>>>> >>>>> OpenStack Development Mailing List (not for usage >>>>> questions) >>>>> Unsubscribe: >>>>> >>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >>>>> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>>> Unless I'm missing some use case, I think that listing >>>>> instances >>>>> for non-admins should be restricted to the instances they own, >>>>> regardless of whether or not they are deleted, period. >>>>> >>>>> >>>>> agree with this. I didn't see a problem showing the deleted >>>>> instance >>>>> for non-admins. >>>>> >>>>> >>>>> As for listing deleting instances as an admin, that was broken >>>>> with the 2.16 microversion and there is a fix here: >>>>> >>>>> https://review.openstack.org/#/c/283820/ >>>>> >>>>> -- >>>>> >>>>> Thanks, >>>>> >>>>> Matt Riedemann >>>>> >>>>> >>>>> >>>>> >>>>> __________________________________________________________________________ >>>>> >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: >>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>> >>>>> <http://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://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 >>>>> >>>>> >>>> [1] >>>> >>>> https://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/servers.py?id=3a0e5f985fdd4b067d68450360cf62d57e82ecb2#n355 >>>> >>>> >>>> >>> I confirmed what you're seeing [1]. A non-admin can use `nova list >>> --deleted` and it's not an error but non-deleted instances are returned. >>> But a non-admin can't use `nova list --status=deleted` because only admins >>> can perform that operation since the REST API code explicitly checks the >>> context. >>> >>> [1] https://gist.github.com/mriedem/1299a15007e413ff646a >>> >>> >>> -- >>> >>> 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
