On 12/10/2013 04:26 PM, David Chadwick wrote:
Hi Arvind
the granularity in naming can be as fine as required i.e. a naming
hierarchy can be as deep as required. So if there is a requirement for
individual endpoints to name their own roles, then the addition of
endpoint_id to the naming structure is fine.
regards
David
On 10/12/2013 16:42, Tiwari, Arvind wrote:
Hi David,
I am cool with the proposal, just wanted to grad you attention on may
question which I asked in my last email (which is below)
Q. what if two (or more) endpoints want to have same role_name for a
service (nova.east.admin, nova.west.admin, nova.north.admin .....)?
(Can we think of adding an optional endpoint_id attribute in role
data model to allow such role, which is also needed to envision
endpoint scoped tokens for our use case)
{ "role": { "id": "76e72a", "domain_id" = "--id--", (optional, if
present, role is named by specific domain) "project_id" = "--id--",
(optional, if present, role is named by project) "service_id" =
"--id--", (optional, if present, role is named by service)
"endpoint_id" = "--id--", (optional, if present, role is named by
service) "name": "---role_name---", (must be unique when combined
with domain, project and service ids) "scope": {"id": "---id---",
(resource_id) "type": "service | file | domain etc.",
"endpoint":"---endpoint---" } } }
For Adam's question " We are not linking role names to service id."
(email attached) AT: These attributes are all optional and will not
stop anyone how don't want to included service_id or (any other
attribute) for role name uniqueness. So in particular deployment want
to keep just the role name unique, this model will not restrict you.
Unnecessary. You are basically putting in documentation about how they
are to be enforced, which does not belong there.
Just do the basic: allow for the role naming to be nested under
projects and domains, and use that to support your use case.
This discussion is taking up too much time and effort. Please stop
trying to make it more complex than necessary.
Thoughts?
Thanks, Arvind
-----Original Message----- From: David Chadwick
[mailto:d.w.chadw...@kent.ac.uk] Sent: Tuesday, December 10, 2013
1:30 AM To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing
List (not for usage questions) Cc: Henry Nash;
dolph.math...@gmail.com; Yee, Guang Subject: Re: [openstack-dev]
[keystone] Service scoped role definition
How about the following which clearly separates naming and scoping
constraints
{ "role": { "id": "76e72a", "domain_id" = "--id--", (optional, if
present, role is named by specific domain) "project_id" = "--id--",
(optional, if present, role is named by project) "service_id" =
"--id--", (optional, if present, role is named by service) "name":
"---role_name---", (must be unique when combined with domain,
project and service ids) "scope": {"id": "---id---", (resource_id)
"type": "service | file | domain etc.", "endpoint":"---endpoint---"
} } }
regards
David
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
