Add Keystone domain RBAC to gnocchi

[jd]

See https://bugs.launchpad.net/gnocchi/+bug/1576804

[ozerovandrei]

@jd Hello.

Right now OpenStack Identity service is moving towards merging Domain construct into a Project one: https://blueprints.launchpad.net/keystone/+spec/reseller https://specs.openstack.org/openstack/keystone-specs/specs/keystone/mitaka/reseller.html

OpenStack users can request a domain-scoped token from the Identity service and work with domain-scoped objects. Unfortunately, such token won't have a project_id value in itself, only domain_id value. (Maybe we will be able to request a domain-scoped token with a project information in the future, who knows).

So, Gnocchi API auth_helper mechanisms won't work with such token:

• get_auth_info() will return the following token:

  {'project_id': None, 'user_id': u'USER_UUID', 'user': u'USER_UUID:', 'roles': [u'_member_'], 'domain_id': u'DOMAIN_UUID'}

• get_current_user() won't work with an empty project_id request
• get_resource_policy_filter() also won't work with an empty project_id request

Currently I need to have some metering data in the domain-scoped measures and resources. So, I checked this issue, read the OpenStack commits about moving to project-only schema and decided to do the following:

• create needed Gnocchi resources that have project_id value populated with the users domain_id uuid
• allow users to request a domain-scoped Identity tokens (their domain_id uuids will equal to their Gnocchi resources project_ids)
• tune Gnocchi API auth_helper a little bit to allow users to get their resources and metrics (I also needed to change the policy.json a little bit)

I've created and referenced a new PR with my changes: #878.

So. I want to ask. What are your plans about Domain RBAC? Do you want to create a new domain_id field in the resource object (like in the launchpad bug, referenced in the description of this issue)? Or it's better to forget about "domain" term (my PR does just that) and name them as "parent project" or "project acting like domain", as the referenced OpenStack bp want us to? In the second case, you don't really need a separate domain_id field in the Gnocchi resource object.

[jd]

Hey @ozerovandrei, thanks for the long analysis, that helps a lot!

The current idea is to remove user_id and project_id from the generic resource and let operators create their own fields.

For the time being, creating resources with domain_id attributes could be enough to address this use case I think.

I don't think I'm qualified enough about Keystone to have a proper answer on what's best. It seems to me having a domain_id field is cleaner though.