nova list ignores --tenant argument

[Victoria Martinez de la Cruz]

It came to my attention that when trying to list the instances of an specific tenant, the --tenant argument provided for the list function is ignored.

The default tenant for this action is OS_TENANT_NAME.

Steps to reproduce:

1. Create one or more instances in different tenants, e.g. demo and demo2
2. Use nova list with --tenant argument initiated with demo's tenant id
3. Use nova list with --tenant argument initiated with demo2's tenant id
4. Check that the output is the same for 2. and 3.

Expected result: Instance list for each tenant

Actual result:

Tenant: demo - Instances: Cirros1.1 and Cirros1.2
Tenant: demo2 - Instances: Cirros2.1 and Cirros 2.2

OS_TENANT_NAME = demo

[vkmc@thermalx2 ~]$ keystone tenant-list
+----------------------------------+--------------------+---------+
| id | name | enabled |
+----------------------------------+--------------------+---------+
| 96776baee20e49c49af03967eb23e9b6 | admin | True |
| fa7880aa16d349fbb925ece6da58e93e | alt_demo | True |
| e449b529f202419994051578e3e639a9 | demo | True |
| 186b554e5b344cc5b0fa2f644d4e73c2 | demo2 | True |
| 9d862590f7ec4d0a993e44f715008fad | invisible_to_admin | True |
| 6e1525e829754ef29c8cabbde9a7566b | service | True |
+----------------------------------+--------------------+---------+
[vkmc@thermalx2 ~]$ nova list --all-tenants 1
+--------------------------------------+-----------+--------+------------------+
| ID | Name | Status | Networks |
+--------------------------------------+-----------+--------+------------------+
| 4f3e08b5-4fb3-405d-a682-41e8840d9227 | Cirros1.1 | ACTIVE | private=10.0.0.3 |
| e74a88c5-de2d-4e9a-893a-d095b6318f61 | Cirros1.2 | ACTIVE | private=10.0.0.4 |
| 5c9c77f8-b272-43b1-80dd-69a26b2890c2 | Cirros2.1 | ACTIVE | net2=192.168.0.3 |
| 2c6ad73b-3dc5-4761-a17f-f544776a86f3 | Cirros2.2 | ACTIVE | net2=192.168.0.4 |
+--------------------------------------+-----------+--------+------------------+
[vkmc@thermalx2 ~]$ nova list --tenant e449b529f202419994051578e3e639a9 (demo)
+--------------------------------------+-----------+--------+------------------+
| ID | Name | Status | Networks |
+--------------------------------------+-----------+--------+------------------+
| 4f3e08b5-4fb3-405d-a682-41e8840d9227 | Cirros1.1 | ACTIVE | private=10.0.0.3 |
| e74a88c5-de2d-4e9a-893a-d095b6318f61 | Cirros1.2 | ACTIVE | private=10.0.0.4 |
+--------------------------------------+-----------+--------+------------------+
[vkmc@thermalx2 ~]$ nova list --tenant 186b554e5b344cc5b0fa2f644d4e73c2 (demo2)
+--------------------------------------+-----------+--------+------------------+
| ID | Name | Status | Networks |
+--------------------------------------+-----------+--------+------------------+
| 4f3e08b5-4fb3-405d-a682-41e8840d9227 | Cirros1.1 | ACTIVE | private=10.0.0.3 |
| e74a88c5-de2d-4e9a-893a-d095b6318f61 | Cirros1.2 | ACTIVE | private=10.0.0.4 |
+--------------------------------------+-----------+--------+------------------+

[Roman Podoliaka (rpodolyaka)]

I've been investigating this bug for a few hours and have found this:

1. --tenant argument is not ignored, novaclient actually does following HTTP query to Nova API:
     GET /v2/43a00152945842f0b2363acc8d7cd41b/servers/detail?project_id=5bafd111e97040d28f48e51f774c5a6f HTTP/1.1

     (where 43a00152945842f0b2363acc8d7cd41b is an admin tenant id, 5bafd111e97040d28f48e51f774c5a6f is a tenant id)

2. Compute API v2 spec (http://docs.openstack.org/api/openstack-compute/2/content/List_Servers-d1e2078.html) for endpoint
     GET /{version}/{tenant_id}/servers/detail doesn't seem to provide the "project_id" filter used by novaclient.

3. Nova code doesn't seem to provide filtering of instances by project_id (nova/nova/api/openstack/compute.py Controller._get_servers()).

Filtering by tenant was added to novaclient by this patch https://review.openstack.org/#/c/16318/2. From what I see the corresponding Nova feature has never been implemented. So I attach Nova as a project affected by this bug.

[Roman Podoliaka (rpodolyaka)]

Update:

1. novaclient uses the wrong filter name: "project_id" instead of "tenant_id".

2. Nova actually has the code to filter instances by tenant id, but it doesn't work properly (nova/nova/compute/api.py):
       filters = {}
       ...
       # search_option to filter_name mapping.
        filter_mapping = {
                'image': 'image_ref',
                'name': 'display_name',
                'tenant_id': 'project_id',
                'flavor': _remap_flavor_filter,
                'fixed_ip': _remap_fixed_ip_filter}

        # copy from search_opts, doing various remappings as necessary
        for opt, value in search_opts.iteritems():
            ...
            (remapping is done here, i. e. filters are put into the "filters" dict under correct names)

The problem is that "search_opts" dict has "project_id" key (which is equal to the id of a tenant that
makes a request, i. e. admin) and the "tenant_id" key (which is used to filter instances by tenant id) and
both of them map to the same entry ("project_id") in the "filters" dict. So one of them will be eventually
overwritten.

query:
GET /v2/43a00152945842f0b2363acc8d7cd41b/servers/detail?tenant_id=5bafd111e97040d28f48e51f774c5a6f

pdb:
   > /opt/stack/nova/nova/compute/api.py(1400)get_all()
   -> for opt, value in search_opts.iteritems():
   (Pdb) search_opts.items()
    [('deleted', False), (u'tenant_id', u'5bafd111e97040d28f48e51f774c5a6f'), ('project_id', u'43a00152945842f0b2363acc8d7cd41b')]

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[Sulochan Acharya (sulochan-acharya)]

All "list" call with admin context have the format:

nova list --all-tenant --{filter}

so --tenant filter that will work is:

nova list --all-tenant --tenant xxxxxx

eg:

 nova list --all-tenant --tenant 8e94857c14df41bba01a8f246526fd0a
+--------------------------------------+-------+--------+----------+
| ID | Name | Status | Networks |
+--------------------------------------+-------+--------+----------+
| 040ac3a9-3756-4ec3-a9cf-1c7a1133ede9 | test1 | ERROR | |
+--------------------------------------+-------+--------+----------+
Searching by: {'deleted': False, u'project_id': u'8e94857c14df41bba01a8f246526fd0a', u'all_tenants': u'1'}

nova list --all-tenant --tenant 2fb142a94c1e40b28cee175fee10aa9f
+--------------------------------------+---------------+--------+----------+
| ID | Name | Status | Networks |
+--------------------------------------+---------------+--------+----------+
| 908ed5f6-a0cb-455f-a09a-84f48ad6299c | alt_demo_test | ERROR | |
+--------------------------------------+---------------+--------+----------+
Searching by: {'deleted': False, u'project_id': u'2fb142a94c1e40b28cee175fee10aa9f', u'all_tenants': u'1'}

The same applies if you want to search by ip,host etc.

Looking at the call, it wont look for project id in search_opts if you dont specify all-tenant.

[Roman Podoliaka (rpodolyaka)]

Yep, that's right. But I'm not sure this is a way it should be (looking at Nova code and unit tests).

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/25535
Committed: http://github.com/openstack/python-novaclient/commit/94173a3f989c87d0dce1ecdc0ad733b4621fea44
Submitter: Jenkins
Branch: master

commit 94173a3f989c87d0dce1ecdc0ad733b4621fea44
Author: Roman Podolyaka <email address hidden>
Date: Wed Mar 27 16:48:02 2013 +0200

    Use correct filter name for listing of instances

    nova list --tenant tenant_id leads to the following query to Nova API:

      GET /v2/{admin_tenant_id}/servers/detail?project_id={tenant_id}

    While Nova actually expects:

      GET /v2/{admin_tenant_id}/servers/detail?tenant_id={tenant_id}

    Fixes bug 1134382.

    Change-Id: I222208bcc9aaf547cd0b1c52dc8856123a823b8e

[Roman Podoliaka (rpodolyaka)]

Current Nova behavior is considered to be right. Marked bug as invalid.