Open Stack

On Tuesday, June 23, 2015 12:14 AM, Adam Young wrote:

> It is not an issue if you keep each of the policy files completely
> separate, but it means that each service has its own meaning for the
> same name, and that confuses operators;  owner in Nova means "a user
> that has a role on this project" where as "owner" in Keystone means
> "Objects associated with a specific user".

I understand your thought came from usability.

But it might increase development complexity, I think each component
doesn't want to define own component name in the policy.json because
it's well-known there.
Unnn... Please forget it (it might be too development thought) :-)

I want to focus on the following topic:

> > My concern now is:
> > * Service Tokens was implemented in Juno [1] but now we are not able
> >   to implement it with Oslo policy without extensions so far.
> > * I think to implement spec[2] needs more time.
> >
> > [1] https://github.com/openstack/keystone-specs/blob/master/specs/keystonemiddleware/implemented/service-tokens.rst
> > [2] https://review.openstack.org/#/c/133855/
> >
> > Is there any way to support spec[1] in Oslo policy? Or
> > Should I wait for spec[2]?
> 
> I'm sorry, I am not sure what you are asking.

I'm sorry let me explain this again.

(1) Keystone supports service tokens [1] from Juno release.
(2) Oslo policy graduated from Kilo release.
(3) Oslo policy doesn't have an ability to deal with the service tokens.
    I'm not 100% sure but in order to support the service tokens Oslo policy
    needs to handle service_roles in addition to roles stored in a credential.
    Current logic:
    If a rule which starts with 'role:', RoleCheck uses 'roles' in the credential.
    code: https://github.com/openstack/oslo.policy/blob/master/oslo_policy/_checks.py#L249
    
    My solution for this now is create ServiceRoleCheck class to handle 'service_roles' in
    the credential. This check will be used when a rule starts with 'srole:'.
    https://review.openstack.org/#/c/149930/15/swift/common/middleware/keystoneauth.py
    L759-L767

I think it's better to handle by Oslo policy because of a common issue. So I would like
to know a plan to handle this issue.

Thanks in advance,
Hisashi Osanai