problem to operate instances with interger like names

[Zhihai Song]

In the process of "nova show XXX". Nova client will first treat XXX as an int value to retrive the information of the instance. Then as an UUID. Finally as the name of the instance.
The logic is here:
https://github.com/openstack/python-novaclient/blob/master/novaclient/utils.py#L190

This becomes a problem when the instance has a interger like name (eg. "5" as the name), and there do exists a instance entry with the ID (not the uuid) that match the interger like name in the DB. Nova client will get this ID = 5 instance instead of the Name = 5 instance.

Is this working as designed?
IMHO, the ID in the instance DB can not be retrived by nova client. So there is no reason for nova client to receive the ID as a parameter.

[Zhihai Song (szhsong)]

I am going to disable nova client to retrive the instance detail by ID.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/246881

[melanie witt (melwitt)]

To clarify, are you saying you receive the wrong instance when you do 'nova show 5' or are you saying unnecessary calls are made when you do 'nova show 5'?

[Zhihai Song (szhsong)]

I mean wrong instance. Since nova client can't get the ID of a resource, it is not reasonable to retrive a resource by its ID through nova client. On the other hand, name and UUID can be known by nova client user. So I put name and UUID before ID in this logic.

[melanie witt (melwitt)]

Okay, I just reproduced this issue using devstack and when there exists an instance whose "id" in the database matches the display name, I get:

$ nova list
+--------------------------------------+------+--------+------------+-------------+------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+------+--------+------------+-------------+------------------+
| 7c7c34aa-1e65-46b9-9541-bda10d50cbf5 | 1 | ACTIVE | - | Running | private=10.0.0.2 |
+--------------------------------------+------+--------+------------+-------------+------------------+
$ nova show 1
ERROR (ClientException): The server has either erred or is incapable of performing the requested operation. (HTTP 500) (Request-ID: req-0778f138-8b85-47b6-be76-2d697334aaef)

with a trace in nova-api.log [1]. All of the code in nova api assumes it's receiving an instance uuid from the client, so even though it retrieves an instance from the database by numeric id, it fails at the api caching layer because it adds the cache entry by uuid. When another extension tries to retrieve the instance from the cache by numeric id, it returns None.

[1] http://paste.openstack.org/show/480694/

[Zhihai Song (szhsong)]

@melanie witt
At first I was wondering why I can do the "nova show 1" with admin user:

jahei@usrvdevstack:~/devstack$ nova show 1
+--------------------------------------+----------------------------------------------------------------+
| Property | Value |
+--------------------------------------+----------------------------------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-AZ:availability_zone | nova |
| OS-EXT-SRV-ATTR:host | usrvdevstack |
| OS-EXT-SRV-ATTR:hostname | inst1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | usrvdevstack |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |
| OS-EXT-SRV-ATTR:kernel_id | 815d7db8-a0ef-4c15-a028-46bff1dbc575 |
| OS-EXT-SRV-ATTR:launch_index | 0 |
| OS-EXT-SRV-ATTR:ramdisk_id | 29c7cfa4-7ecc-4a3b-add8-9ac0730762bb |
| OS-EXT-SRV-ATTR:reservation_id | r-5jvmr7z0 |
| OS-EXT-SRV-ATTR:root_device_name | /dev/vda |
| OS-EXT-SRV-ATTR:user_data | - |
| OS-EXT-STS:power_state | 1 |
| OS-EXT-STS:task_state | - |
| OS-EXT-STS:vm_state | active |
| OS-SRV-USG:launched_at | 2015-10-28T09:18:49.000000 |
| OS-SRV-USG:terminated_at | - |
| accessIPv4 | |
| accessIPv6 | |
| config_drive | True |
| created | 2015-10-28T09:18:24Z |
| flavor | m1.tiny (1) |
| hostId | 654744d5f84cf5f3a1672900541001f7d694fdfb3098bc0ff58c524f |
| id | 6a392f64-7a04-4b7d-9494-2650f36a6201 |
| image | cirros-0.3.4-x86_64-uec (a37d9db8-a33a-4173-9345-70b15148de79) |
| key_name | - ...

[Zhihai Song (szhsong)]

melanie witt opened a bug for the problem mentioned above.
https://bugs.launchpad.net/nova/+bug/1522536

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/246881
Committed: https://git.openstack.org/cgit/openstack/python-novaclient/commit/?id=11e0782f62e82a4a7e11dcbddd90403d5082af68
Submitter: Jenkins
Branch: master

commit 11e0782f62e82a4a7e11dcbddd90403d5082af68
Author: Zhihai <email address hidden>
Date: Wed Nov 18 11:21:33 2015 +0000

    Change the logic for the client to retrive resources

    The ID (primary key) of a resource can not be retrived by the client.
    There is no sense to provide the functionality to get an resource by
    its ID. Especially when an instance is named by an interger, client
    will try to get the instance with the ID of that interger value.
    This patch will change the order in which the novaclient retrive
    resources. First by UUID, then by name, finally by the ID. This will
    also reduce api call overhead, since UUID is used mostly.

    Change-Id: I0bfa5cb03a04625c3def5608dd4529e52d50f944
    Closes-Bug: #1516924

[Davanum Srinivas (DIMS) (dims-v)]

This issue was fixed in the openstack/python-novaclient 3.1.0 release.