Description of problem: When trying to filter instances based on the following search keys in horizon dashboard as _member_ user,filter is not working since it returns all instances. - ID - key-pair name - availability zone - vCPUs Version-Release number of selected component (if applicable): Openstack-13 How reproducible: I am able to reproduce in my environment & here are my findings. 1. With Member user :- When we made search on basis of 'keypair_name' on horizon.Found below request on nova-api ~~~ 2019-09-07 14:37:12.175 16 DEBUG nova.api.openstack.wsgi [req-387de6a7-50b2-4090-a535-2ff4d61e33b5 062b39e07cde438080b7c31818124e4d 3e959223ee544387b6efe0ce5733d32c - default default] Calling method '<bound method ServersController.detail of <nova.api.openstack.compute.servers.ServersController object at 0x7fc96d1852d0>>' _process_stack /usr/lib/python2.7/site-packages/nova/api/openstack/wsgi.py:607 2019-09-07 14:37:12.180 16 DEBUG nova.api.openstack.compute.servers [req-387de6a7-50b2-4090-a535-2ff4d61e33b5 062b39e07cde438080b7c31818124e4d 3e959223ee544387b6efe0ce5733d32c - default default] Removing options 'key_name, project_id, limit' from query remove_invalid_options /usr/lib/python2.7/site-packages/nova/api/openstack/compute/servers.py:1159 <<<<<<<<<<<< 2019-09-07 14:37:12.180 16 DEBUG nova.compute.api [req-387de6a7-50b2-4090-a535-2ff4d61e33b5 062b39e07cde438080b7c31818124e4d 3e959223ee544387b6efe0ce5733d32c - default default] Searching by: {'deleted': False, 'project_id': u'3e959223ee544387b6efe0ce5733d32c'} get_all /usr/lib/python2.7/site-packages/nova/compute/api.py:2419 ~~~~ Notice (ii) from above options 'key_name' terms is ignored . 2. With admin user: Notice on (ii) below it starts searching with 'key_name' as 'key1'. ~~~ 2019-09-07 14:50:50.849 16 DEBUG nova.api.openstack.wsgi [req-0a381f55-f1f1-4149-9319-70be2fcf90e6 685624595ee4417aa5bd4d865462922b 3e959223ee544387b6efe0ce5733d32c - default default] Calling method '<bound method ServersController.detail of <nova.api.openstack.compute.servers.ServersController object at 0x7efee49aa310>>' _process_stack /usr/lib/python2.7/site-packages/nova/api/openstack/wsgi.py:607 2019-09-07 14:50:50.855 16 DEBUG nova.compute.api [req-0a381f55-f1f1-4149-9319-70be2fcf90e6 685624595ee4417aa5bd4d865462922b 3e959223ee544387b6efe0ce5733d32c - default default] Searching by: {'deleted': False, u'key_name': u'key1', u'project_id': u'3e959223ee544387b6efe0ce5733d32c'} get_all /usr/lib/python2.7/site-packages/nova/compute/api.py:2419 ~~~ I just dig out the codes why 'keypair' is ignored,I found this option is only allowed for user having(if context.is_admin) admin role. ~~~ def remove_invalid_options(context, search_options, allowed_search_options): """Remove search options that are not valid for non-admin API/context.""" if context.is_admin: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< context.is_admin # Only remove parameters for sorting and pagination for key in ('sort_key', 'sort_dir', 'limit', 'marker'): <<<<<<<<<<<<<<<<<<<<< search_options.pop(key, None) return # Otherwise, strip out all unknown options ~~~ By checking policy.json context_is_admin is allowed only for admin user. ~~~ [root@overcloud-controller-2 ~]# grep -ir context_is_admin nova_policy "context_is_admin": "role:admin" <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ~ ~~~ Now i can only this for member users also ,just by changing 'context_is_admin' as below but on controllers but this is very **dangerous** & not recommended to perform even it's not recommended to tweak default policy files. ~~~ [root@overcloud-controller-2 ~]# grep -ir context_is_admin /var/lib/config-data/puppet-generated/nova/etc/nova/policy.json "context_is_admin": "" <<<<<<<<< ~~~ >>Now if we test filtering instances by keypair from member user it will work. But modifying above policy means all members have admin command rights? I want to know best way to achieve this. Steps to Reproduce: 1. 2. 3. Actual results: For member user filtering doesn't work. Expected results: Cu exepcting this to work. Additional info:
Hello. Is there any reason why this was reported as an RFE? This is a bug, not an enhancement.
I can't speak for Horizon, but for Nova at least, the following filter keys are administrator-only, as specified in our api-ref [1]: > availability_zone (Optional) > Filter the server list result by server availability zone. > This parameter is only valid when specified by administrators. If non-admin users specify this parameter, it is ignored. > key_name (Optional) > Filter the server list result by keypair name. > This parameter is only valid when specified by administrators. If non-admin users specify this parameter, it is ignored. > uuid (Optional) > Filter the server list result by the UUID of the server. > This parameter is only valid when specified by administrators. If non-admin users specify this parameter, it is ignored. vCPUs is not a filter key that Nova supports, it must be something specific to Horizon. [1] https://docs.openstack.org/api-ref/compute/?expanded=list-servers-detailed-detail#list-servers-detailed
Sorry, I misunderstood the initial report. What you're essentially asking for is a granular policy specifically for filtering in the servers-detail API, because you don't to make everybody an admin (and rightfully so). I'm not sure whether this would be a bug or an RFE, though I'm leaning towards the latter, as nothing is technically broken. I also want to set expectations that this would be fairly low priority work.
Hi Artrom, No issue, eventually I opened this BZ as RFE but later on Tomas thinks this is a bug so I marked it accordingly. Priority is fine for me since it meets the priority of the case.It all depends upon customer how urgent this is for them.
The BZ currently isn't targeted at OSP17/Ussuri, so the earliest we would get to it would be the OSP18/V cycle.
Microversion 2.83, which will be included in OSP 17.0, adds support for the following non-admin filters: - availability_zone - config_drive - key_name - created_at - launched_at - terminated_at - power_state - task_state - vm_state - progress - user_id Sounds like this is what you want so I'm marking this as fixed.
We picked this up from upstream from https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id76 - setting OtherQA because I don't think we need to QA this, just a release note.
Hi, Not all of the parameters that Stephen mentions in Comment 10 have been exposed in the OpenStack Client downstream. These parms are NOT present downstream: - created_at - launched_at - terminated_at See: https://github.com/openstack/python-openstackclient/blob/master/openstackclient/compute/v2/server.py#L1853 Thanks to Sean and Artom for their help with this! Best, --Greg
According to our records, this should be resolved by openstack-nova-23.2.2-0.20220720130412.7074ac0.el9ost. This build is available now.
(In reply to Greg Rakauskas from comment #24) > Hi, > > Not all of the parameters that Stephen mentions in Comment 10 have been > exposed > in the OpenStack Client downstream. These parms are NOT present downstream: > > - created_at > - launched_at > - terminated_at > > See: > > > https://github.com/openstack/python-openstackclient/blob/master/ > openstackclient/compute/v2/server.py#L1853 As a general point, we probably don't actually want to expose those as they're not particularly useful. These are effectively exact match filters and don't allow for ranges. You could, for example, drop the time component and filter by day (or drop the day component and filter by month) but you can't filter by a range. To do that, you'd normally use the '--changes-since' and '--changes-before' filters instead. These aren't exactly the same but can give useful output when combined with the the '--status' option (e.g. only deleted instances will have a 'terminated_at' value, so you could combine '--changes-(since|before)' with '--status DELETED' to only show deleted instances). If someone thinks someone is looking for this, we can easily add it. I doubt they are though. I also note that novaclient doesn't expose this.
Hi Stephen, To be clear, the three parameters mentioned in Comment 28 are not supported in the downstream CLI and therefore are not documented in the downstream doc. Your workaround does sound useful. Thanks for adding it! Thanks, --Greg