Show_project?

[xuhang57]

Currently, we don't have a CLI that allows an admin to see who is in which project(s). Should we create a new API and CLI to support this feature?

Any idea is more than welcome!

[naved001]

Currently we have:

• list_project_networks
• list_project_nodes
• list_project_headnodes (will be marked deprecated soon)

The only thing we don't have is list_project_users. We could write a wrapper on top of the list_users api that will filter by the project so that will be equivalent of list_project_users.

That would cover everything we need to know about a project. Show_project could also be just a cli command that makes these 4 calls to get all the information.

[zenhack]

My instinct is to keep this out of the server, since as you point out it can be implemented on top of the existing calls.

[xuhang57]

sounds good, so we need a list_project_users(project) then?

@zenhack does that make sense? If I understand what you mean by "keep this out of the server", we don't need a show_project(project) because of the reasons Naved have said.

[zenhack]

We can build list_project_users on top of what you're doing in #945, so I don't think any changes are needed to the server at all.

[naved001]

while we are on the topic, should we update list_projects to show the projects a non-admin user has access to? Just like list_project_networks.

Right now a regular user can't see what projects they have access to.

This was brought up by @pns005

[xuhang57]

so modify the call, when an admin calls it, it shows projects and all users in those projects. For a regular user, only show project that the user has the access to?

For admin-user 2 projects: [{"name": "naved", "users": ["naved", "lucas"]}, {"name": "lucas", "users": ["lucas"]}

regular-user: 1 project: {"lucas"}

[naved001]

it only lists projects right now and not the users assigned to it. And I am okay with it because one could just list_users and grep for the project.

The only update I would like to see is that non-admin users can at least see the projects they have access to. What do you think @zenhack ?

[zenhack]

The more I think about it the less comfortable I am adding calls that have different behavior based on the identity of the caller (besides just allow/deny). I worry it makes use of the API less predictable.

I'm also against adding too many calls that are specific to this auth backend; I'd like the API usage to as much as possible be independent of how we authenticated.

[naved001]

I worry it makes use of the API less predictable.

That's a good point. But what do we do about regular users not being able to see what projects they are a part of?

[zenhack]

We could have a "show_user":

GET /users/<me>.

...but it doesn't nicely fit into the current authorization framework (which is based on project access), which I'm not happy about. Will keep thinking.

[xuhang57]

https://github.com/CCI-MOC/hil/issues/722 Loop in this issue

[naved001]

Keystone already has an API https://developer.openstack.org/api-ref/identity/v3/#get-available-project-scopes

We have to think of a way to implement this in our db backend.