nova show <name> doesn't work when the instance name contains special characters such as ()[]{}

Bug #2025358 reported by Yamato Tanaka
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
python-novaclient
Invalid
Undecided
Yamato Tanaka

Bug Description

Description
===========

I created an instance whose name is "test(test)".

~~~
[stack@utils devstack]$ /usr/local/bin/nova list
nova CLI is deprecated and will be a removed in a future release
+--------------------------------------+-----------------------------------------------+--------+------------+-------------+---------------------------------------------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+-----------------------------------------------+--------+------------+-------------+---------------------------------------------------------+
| b477e3cd-4392-447f-a54f-c97d9097f5b5 | test(test) | ACTIVE | - | Running | private=10.0.0.13, fda4:8535:6684:0:f816:3eff:fedf:3bff |
+--------------------------------------+-----------------------------------------------+--------+------------+-------------+---------------------------------------------------------+
~~~

However, nova show 'test(test)' doesn't work.
Nova API returns no instances.

~~~
[stack@utils devstack]$ /usr/local/bin/nova --debug show 'test(test)'
  :
DEBUG (connectionpool:456) http://10.0.0.253:80 "GET /compute/v2.1/servers?name=test%28test%29 HTTP/1.1" 200 15
DEBUG (session:542) RESP: [200] Connection: close Content-Length: 15 Content-Type: application/json Date: Thu, 29 Jun 2023 11:36:39 GMT OpenStack-API-Version: compute 2.95 Server: Apache/2.4.53 (Red Hat Enterprise Linux) OpenSSL/3.0.7 mod_wsgi/4.7.1 Python/3.9 Vary: OpenStack-API-Version,X-OpenStack-Nova-API-Version X-OpenStack-Nova-API-Version: 2.95 x-compute-request-id: req-ffc5c0f1-63df-4de8-b736-fc88f7ab37b5 x-openstack-request-id: req-ffc5c0f1-63df-4de8-b736-fc88f7ab37b5
DEBUG (session:574) RESP BODY: {"servers": []}
DEBUG (session:946) GET call to compute for http://10.0.0.253/compute/v2.1/servers?name=test%28test%29 used request id req-ffc5c0f1-63df-4de8-b736-fc88f7ab37b5
DEBUG (shell:835) No server with a name or ID of 'test(test)' exists.
~~~

The reason why Nova API returns no instances is that "name" attribute of the API is considered as a regular expression.

https://docs.openstack.org/api-ref/compute/?expanded=list-servers-detail
> name (Optional)
> query
> string
> Filters the response by a server name, as a string. You can use regular expressions in the query.

When I escape special characters like 'test\(test\)', nova API returns the instance information, but nova cli drops it.
`nova show` still doesn't work.

~~~
DEBUG (session:511) REQ: curl -g -i -X GET http://10.0.0.253/compute/v2.1/servers?name=test%5C%28test%5C%29 -H "Accept: application/json" -H "OpenStack-API-Version: compute 2.95" -H "User-Agent: python-novaclient" -H "X-Auth-Token: {SHA256}3d81bc6322a0a7276b85ca2b0cbf24cfd7298d20bce6bb24e3c27b24355a9c85" -H "X-OpenStack-Nova-API-Version: 2.95"
DEBUG (connectionpool:273) Resetting dropped connection: 10.0.0.253
DEBUG (connectionpool:456) http://10.0.0.253:80 "GET /compute/v2.1/servers?name=test%5C%28test%5C%29 HTTP/1.1" 200 301
DEBUG (session:542) RESP: [200] Connection: close Content-Length: 301 Content-Type: application/json Date: Thu, 29 Jun 2023 11:37:30 GMT OpenStack-API-Version: compute 2.95 Server: Apache/2.4.53 (Red Hat Enterprise Linux) OpenSSL/3.0.7 mod_wsgi/4.7.1 Python/3.9 Vary: OpenStack-API-Version,X-OpenStack-Nova-API-Version X-OpenStack-Nova-API-Version: 2.95 x-compute-request-id: req-0d479d7b-9229-4953-9b05-51ab9d5470f6 x-openstack-request-id: req-0d479d7b-9229-4953-9b05-51ab9d5470f6
DEBUG (session:574) RESP BODY: {"servers": [{"id": "b477e3cd-4392-447f-a54f-c97d9097f5b5", "name": "test(test)", "links": [{"rel": "self", "href": "http://10.0.0.253/compute/v2.1/servers/b477e3cd-4392-447f-a54f-c97d9097f5b5"}, {"rel": "bookmark", "href": "http://10.0.0.253/compute/servers/b477e3cd-4392-447f-a54f-c97d9097f5b5"}]}]}

  ===> nova api returned instance information

DEBUG (session:946) GET call to compute for http://10.0.0.253/compute/v2.1/servers?name=test%5C%28test%5C%29 used request id req-0d479d7b-9229-4953-9b05-51ab9d5470f6
DEBUG (shell:835) No server with a name or ID of 'test\(test\)' exists.

  ===> however, nova cli dropped the information.
~~~

The reason nova cli dropped the information is that it compares the instances name by exact matching whereas Nova API compares the instance name by regular expression matching.

~~~
https://github.com/openstack/python-openstackclient/blob/stable/train/openstackclient/compute/v2/server.py#L2515
https://github.com/openstack/osc-lib/blob/db9cdc95ed96045ff47c02cf822b1ba90ffa67b0/osc_lib/utils/__init__.py#L241
https://github.com/openstack/python-novaclient/blob/stable/train/novaclient/base.py#L418
https://github.com/openstack/python-novaclient/blob/stable/train/novaclient/base.py#L477-L486

        for obj in listing:
            try:
                if all(getattr(obj, attr) == value <=====================(*)
                        for (attr, value) in searches):
                    if detailed:
                        found.append(obj)
                    else:
                        detail = self.get(obj.id)
                        found.append(detail)
                        found.append_request_ids(detail.request_ids)

   ==> In novaclient implementation, perfect matching is done on the line(*)
   ==> That's why the instance information is discorded.
~~~

I came up with the following four ideas to solve this.

1. Modify Nova API to consider display_name as a normal string, not regular expression
     ==> Modifying API is not allowed. I think we cannot adopt this idea.

2. Modify nova cli to do regular expression check instead of perfect matching.
     ==> I think this change makes the behavior weird. I think most users of `nova show` expects perfect matching, not regular expression matching.

3. Modify nova cli to escape special characters before calling Nova API.
     ==> I think this is the most reasonable. But I think we need to investigate the effects of this change. Additionally, we need pay attention that regular expression format may vary depending on the database backend.

4. Suffer this behavior as an restriction of `nova show`
     ==> This is the most easiest way. But I think it's better to state this restriction somewhere.

IMO, I prefer the 3rd idea.

Steps to reproduce
==================
1. create an instance with name 'test(test)'
2. run nova show 'test(test)'

Expected result
===============
Instance information is shown

Actual result
=============
The following message is shown
~~~
[stack@utils devstack]$ /usr/local/bin/nova show 'test(test)'
nova CLI is deprecated and will be a removed in a future release
ERROR (CommandError): No server with a name or ID of 'test(test)' exists.
~~~

Environment
===========
Master branch deployed by devstack
  and
Red Hat OpenStack Platform 16.2.5, which is based on Train

Changed in python-novaclient:
assignee: nobody → Yamato Tanaka (yatanaka-1007)
Revision history for this message
Yamato Tanaka (yatanaka-1007) wrote :

I was talking with my colleague and came to the following conclusion:

~~~
After discussing this issue with the team internally, this issue was already reported, but we considered it not a bug. Mainly because it can be "workaround" using the id.
We don't want to change anything in the client implementation as they are many implications.

One of the main reasons is that the API's regex is dependent on the underlying database. And users should not be aware of that.
So the team chooses to keep the actual code unchanged and document this behavior as a short and middle-term solution.

However, the team is not opposed to deal with this problem as a long-term solution by changing the API modifying and making the regex a standard Python one and then enabling the usage of it by the client.
~~~

At this moment, I'm closing this ticket with "Invalid" status.

Changed in python-novaclient:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.