Retrieving either a project's parents or subtree as_list does not work

Bug #1506653 reported by Timothy Symanczyk
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
Medium
Lance Bragstad

Bug Description

To reproduce this I created five projects ("1", "2", "3", "4", "5") - with "1" as the top level project, and each subsequent project as a child of the previous. All four of the following calls were performed against project "3".

parents_as_list (NON-working) :
$ curl -i -H"X-Auth-Token:$TOKEN" -H "Content-type: application/json" http://community:35357/v3/projects/b4a6fb7dcc504373a2e1301ab357d248?parents_as_list
{
  "project": {
    "name": "3",
    "is_domain": false,
    "description": "",
    "links": {
      "self": "http://community:35357/v3/projects/b4a6fb7dcc504373a2e1301ab357d248"
    },
    "enabled": true,
    "id": "b4a6fb7dcc504373a2e1301ab357d248",
    "parent_id": "0b09fce9246f42dda11125d4d32aa013",
    "parents": [],
    "domain_id": "default"
  }
}

parents_as_ids (working) :
$ curl -i -H"X-Auth-Token:$TOKEN" -H "Content-type: application/json" http://community:35357/v3/projects/b4a6fb7dcc504373a2e1301ab357d248?parents_as_ids
{
  "project": {
    "name": "3",
    "is_domain": false,
    "description": "",
    "links": {
      "self": "http://community:35357/v3/projects/b4a6fb7dcc504373a2e1301ab357d248"
    },
    "enabled": true,
    "id": "b4a6fb7dcc504373a2e1301ab357d248",
    "parent_id": "0b09fce9246f42dda11125d4d32aa013",
    "parents": {
      "0b09fce9246f42dda11125d4d32aa013": {
        "7092bca4a8d444619bcee53a47585876": null
      }
    },
    "domain_id": "default"
  }
}

subtree_as_list (NON-working) :
$ curl -i -H"X-Auth-Token:$TOKEN" -H "Content-type: application/json" http://community:35357/v3/projects/b4a6fb7dcc504373a2e1301ab357d248?subtree_as_list
{
  "project": {
    "name": "3",
    "is_domain": false,
    "description": "",
    "links": {
      "self": "http://community:35357/v3/projects/b4a6fb7dcc504373a2e1301ab357d248"
    },
    "enabled": true,
    "subtree": [],
    "id": "b4a6fb7dcc504373a2e1301ab357d248",
    "parent_id": "0b09fce9246f42dda11125d4d32aa013",
    "domain_id": "default"
  }
}

subtree_as_ids (working) :
$ curl -i -H"X-Auth-Token:$TOKEN" -H "Content-type: application/json" http://community:35357/v3/projects/b4a6fb7dcc504373a2e1301ab357d248?subtree_as_ids
{
  "project": {
    "name": "3",
    "is_domain": false,
    "description": "",
    "links": {
      "self": "http://community:35357/v3/projects/b4a6fb7dcc504373a2e1301ab357d248"
    },
    "enabled": true,
    "subtree": {
      "421143ab145e4b278d1b971d6509dd23": {
        "1484a4e8493d4f3eb6a81bef582f455a": null
      }
    },
    "id": "b4a6fb7dcc504373a2e1301ab357d248",
    "parent_id": "0b09fce9246f42dda11125d4d32aa013",
    "domain_id": "default"
  }
}

Revision history for this message
Lance Bragstad (lbragstad) wrote :

I seem to be able to recreate. I used the following:

I created the following projects:

22ca44c4f9174cf68b221b260c446a8d great-great-grandparent
21265233cbbd4fe68ad32adcd7162cea great-grandparent
33123935a6e343029ea24feedc5916b2 grandparent
34590cda7de2440188017ddc845fe2e5 parent
89254075048c4300a105da1b39284d10 child

Where each project is the child of the project listed above. In this case, great-great-grandparent is the top level project. So following Tim's case, I did all my calls against the grandparent project.

parents_as_list: http://cdn.pasteraw.com/ajjc1owd5efcr6xwtsdbj7nqcq6cw6e
  returns no parents - fail
parents_as_ids: http://cdn.pasteraw.com/abdd3la2924agvsl1ihbqmn6yxhhw6v
  returns the ids of great-grandparent and great-great-grandparent - success
subtree_as_list: http://cdn.pasteraw.com/egb84jk3yky1s3f2rsoh7p9ofvjq2kq
  returns no subtree - fail
subtree_as_ids: http://cdn.pasteraw.com/828b49094kldix1cldefywemuap4kf2
  returns the ids of parent and child - success

I did the same calls with parent as the project and the following was returned:
parents_as_list: http://cdn.pasteraw.com/epzss1vm0x2gz5bna4f8aehtt4mhk9y
  returns no parents - fail
parents_as_ids: http://cdn.pasteraw.com/sh2z02t9roq9cis6zqfs9eenrtz0n2u
  returns grandparent, great-grandparent, and great-great-grandparent - success
subtree_as_list: http://cdn.pasteraw.com/1ssjr51weuj4zii2k689nf9kc3cnhrw
  returns no subtree - fail
subtree_as_ids: http://cdn.pasteraw.com/aq0vjpkk9jaz26rzplptqxcse4nv3ni
  returns the child id in subtree - success

It appears the behavior is consistent regardless of the depth of the project.

Changed in keystone:
status: New → Confirmed
importance: Undecided → High
Revision history for this message
Lance Bragstad (lbragstad) wrote :

Hi Tim,

I was able to bring this to htruta and raildo, who implemented this functionality. It turns out there is a fundamental difference in subtree_as_ids and subtree_as_list. Being able to get the subtree_as_ids doesn't require any role assignments on the subtree. With that in mind, an admin would be able to list all the subtree ids of a project. Since subtree_as_list returns *more* information about each project in the subtree, this query string only returns subtrees that the user has role assignments on. So, if an admin doesn't have any role assignments on any of the projects in the tree, the call won't return any information in the subtree.

The same applies directly to parents_as_list and parents_as_ids.

Essentially, it boils down to the fact that listing by ids doesn't require additional role assignments, but requesting information by list does.

There is some documentation around the query strings [0], but it doesn't include any information around the role assignments and that behavioral difference. The call is working as expected but I believe the docs could be improved.

[0] https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3.rst#get-project

tags: added: documentation
Changed in keystone:
importance: High → Medium
Revision history for this message
Lance Bragstad (lbragstad) wrote :

Actually, I have a few free cycles right now... Working on a patch to improve the documentation around these query strings.

Changed in keystone:
assignee: nobody → Lance Bragstad (lbragstad)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to keystone-specs (master)

Related fix proposed to branch: master
Review: https://review.openstack.org/235971

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to keystone-specs (master)

Reviewed: https://review.openstack.org/235971
Committed: https://git.openstack.org/cgit/openstack/keystone-specs/commit/?id=17129323aefaf969091d02f371092864ec7404ae
Submitter: Jenkins
Branch: master

commit 17129323aefaf969091d02f371092864ec7404ae
Author: Lance Bragstad <email address hidden>
Date: Fri Oct 16 15:10:37 2015 +0000

    Improve get project query strings

    This commit improves the documentation describing the parents_as_list,
    parents_as_ids, subtree_as_list, and subtree_as_ids query strings.

    Change-Id: I21b4dcf1c3e3afe128658cad55222468803e3947
    Related-Bug: 1506653
    Closes-Bug: 1506986

Revision history for this message
Lance Bragstad (lbragstad) wrote :

Timothy,

Is this still an issue or can this bug be closed out as a documentation fix?

Revision history for this message
Timothy Symanczyk (timothy-symanczyk) wrote :

As far as I'm concerned, the documentation fix provided addresses my original issue very well and this bug can be closed.

Revision history for this message
Timothy Symanczyk (timothy-symanczyk) wrote :
Changed in keystone:
status: Confirmed → Fix Released
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.