My biggest concern is that there is a role struct that is defined as just an ID. A true Role struct with name, domain_id, ID, etc is more correct.

Agreed. the roles.Role struct most definitely needs fleshed out.

I would prefer to at a minimum rename the existing Role struct to something else

six-one-way-half-a-dozen-the-other :)

Either adding additional fields to the current Role struct and creating something like a RoleAssignment struct or renaming the existing Role to RoleAssignment and creating a new Role struct with all known fields that a GET would return.

Whatever the names turn out to be, I do understand what you're saying here and I agree.

The others (user, group) would just be potentially confusing.

Just to be overly verbose on this one, the roles.User, roles.Project, etc structs, while initially looking incorrect, are actually correct from the point of view of the role_assignments API call.

If it turns out there is another role API call which would return the full amount of information for any of these, then either we can look at importing the users.User, projects.Project structs or doing the same thing as renaming roles.Role. Adding on to the latter, renaming roles.Project to roles.ProjectAssignment (or something similar) might be a good long-term idea.

And for even more verbosity, I did a raw curl command, and can confirm that role_assignments is indeed not sending back the full amount of information, so we must adhere to this, in some way, in the roles package:

#!/bin/bash

oscurl() {                                     
  token=$(openstack token issue -c id -f value)
  curl -s -H "X-Auth-Token:$token" $1          
}                                              

oscurl http://localhost:35357/v3/role_assignments?include_names=True | python -mjson.tool

That yields output like the following:

{
    "links": {
        "next": null,
        "previous": null,
        "self": "http://localhost:35357/v3/role_assignments?include_names=True"
    },
    "role_assignments": [
        {
            "links": {
                "assignment": "http://localhost:35357/v3/projects/9b0e16aeb6934f06ab1d87036052bbcb/users/130bd6dcc4014804beb25490b652dceb/roles/f3f979f71d924db69154ccdb4b9b5c03"
            },
            "role": {
                "id": "f3f979f71d924db69154ccdb4b9b5c03",
                "name": "admin"
            },
            "scope": {
                "project": {
                    "domain": {
                        "id": "default",
                        "name": "Default"
                    },
                    "id": "9b0e16aeb6934f06ab1d87036052bbcb",
                    "name": "services"
                }
            },
            "user": {
                "domain": {
                    "id": "default",
                    "name": "Default"
                },
                "id": "130bd6dcc4014804beb25490b652dceb",
                "name": "nova"
            }
        },

It looks like Names was introduced in Keystone 3.6. Given I can use ?include_names=True in an Ocata environment without any microversion customization, I think we can add Name to the various roles struct... but that doesn't have to be immediately done.

Add ListRoles function to Keystone v3 #550

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions