nova show <name> doesn't work when the instance name contains special characters such as ()[]{}
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-
+------
~~~
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
DEBUG (session:542) RESP: [200] Connection: close Content-Length: 15 Content-Type: application/json Date: Thu, 29 Jun 2023 11:36:39 GMT OpenStack-
DEBUG (session:574) RESP BODY: {"servers": []}
DEBUG (session:946) GET call to compute for http://
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:/
> 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://
DEBUG (connectionpool
DEBUG (connectionpool
DEBUG (session:542) RESP: [200] Connection: close Content-Length: 301 Content-Type: application/json Date: Thu, 29 Jun 2023 11:37:30 GMT OpenStack-
DEBUG (session:574) RESP BODY: {"servers": [{"id": "b477e3cd-
===> nova api returned instance information
DEBUG (session:946) GET call to compute for http://
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:/
https:/
https:/
https:/
for obj in listing:
try:
if all(getattr(obj, attr) == value <======
==> 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) |
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.