utils.find_resource return resource not depends on query

[Eugeniya Kudryashova]

When I have one group, the query /groups?display_name=bogus returns:

{u'groups': [{u'id': u'6ce42989b4ae41f89323813812ca6208', u'name': u'asdf', u'domain_id': u'default', u'links': {u'self': u'http://172.20.1.112:5000/v3/groups/6ce42989b4ae41f89323813812ca6208'}, u'description': u''}], u'links': {u'self': u'http://172.20.1.112:5000/v3/groups', u'next': None, u'previous': None}}

Even though the query did not match the query string.

I have defined only one resource of keystone (one user and one group), then I try command which call method utils.find_resource.
This resource would be returned by utils.find_resource not depends on what was specified as name or id.

Examples:
(.venv)stack@eu:/opt/stack/python-openstackclient$ openstack user list --role --os-identity-api-version 3 non_existing_user

| 54fbed994dc84616b2118e4fe6b77d8f | Member |

(.venv)stack@eu:/opt/stack/python-openstackclient$ openstack user list --role --os-identity-api-version 3 admin

| 54fbed994dc84616b2118e4fe6b77d8f | Member |

openstack group list --role --os-identity-api-version 3 --domain admin group_not_exist

| 54fbed994dc84616b2118e4fe6b77d8f | Member | Default | t_dr |

So, utils.find_resource tries to find user/group with incorrect names but doesn't fail in case when only one resource of such type is specified. But it should raise an exception that it can't find resource with specified name or ID.

I tried this also with nova and cinder commands, it works correct with this services.

[Terry Howe (thowe-g)]

Problem original opened as openstack client issue, but seems to be a problem with keystone. I've updated the description.

[Dolph Mathews (dolph)]

Keystone doesn't support "display_name" (as a query parameter or a resource attribute) - is that what OSC is passing to keystoneclient to filter by?

[Steve Martinelli (stevemar)]

@Terry, it looks like the error is here:

https://github.com/openstack/python-openstackclient/blob/master/openstackclient/identity/v3/user.py#L201..#L212

If user is not found, it likely is set to None, then we call the identity client with None as the user argument (which is the default behaviour when listing all roles).

@Dolph, yes, OSC is sending 'display_name' as the last possible attempt in https://github.com/openstack/python-openstackclient/blob/master/openstackclient/common/utils.py#L69

I think, for this instance, we could put a guard and check to see if user is None or not, before trying to list its roles.

[Terry Howe (thowe-g)]

No, I can't reproduce the problem with https://github.com/openstack/python-openstackclient/blob/master/openstackclient/identity/v3/user.py#L201..#L212
If I supply a bogus user for that, I get a "not found" error.

I only get the problem with group finds and it may be related to having only 1 group. It is simply that keystone returns a group with the bogus filter. For example:

    (.venv)terry@brat:~/hp/python-openstackclient$ os group show --os-identity-api-version 3 bogus
    +-------------+-----------------------------------------------------------------------------------+
    | Field | Value |
    +-------------+-----------------------------------------------------------------------------------+
    | description | |
    | domain_id | default |
    | id | 6ce42989b4ae41f89323813812ca6208 |
    | links | {u'self': u'http://172.20.1.112:5000/v3/groups/6ce42989b4ae41f89323813812ca6208'} |
    | name | asdf |
    +-------------+-----------------------------------------------------------------------------------+
    (.venv)terry@brat:~/hp/python-openstackclient$

I'm not saying what OSC does is right with display_name, I was really just giving the keystone folks a chance to look at the bogus filter issue.

[Terry Howe (thowe-g)]

Somewhat related, I attempted to fix cinderclient which AFAIK is the only one that needs this display_name hack, but I just gave up:

https://review.openstack.org/#/c/80672

[Terry Howe (thowe-g)]

https://review.openstack.org/#/c/95041/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/95041
Committed: https://git.openstack.org/cgit/openstack/python-openstackclient/commit/?id=0b2987fef389603b95b2ba7b788492b8baa56745
Submitter: Jenkins
Branch: master

commit 0b2987fef389603b95b2ba7b788492b8baa56745
Author: Terry Howe <email address hidden>
Date: Thu May 22 17:38:41 2014 -0600

    Fix find_resource for keystone and cinder

    The find_resource method had two hacks in in to support cinder
    and keystone and I have removed those in favor of a monkey patch
    for cinder.

    The find_resource method used to attempt to UUID parse the id, but
    it would do a manager.get anyway. I changed it to skip the UUID
    parsing. This will make things run minorly faster and it supports
    LDAP for keystone.

    The find_resource used to attempt to use display_name=name_or_id
    when finding. This was a hack for cinder support, but it breaks
    keystone because keystone totally messes up with the bogus filter
    and keystone refuses to fix it.

    Change-Id: I66e45a6341f704900f1d5321a0e70eac3d051665
    Closes-Bug: #1306699