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
<mailto: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 <mailto: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 <mailto: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>
<mailto: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>
<mailto: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://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://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://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
[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://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
