Open Stack

On Wed, 2012-10-10 at 16:59 +0100, Mark McLoughlin wrote:
> So, we're talking about this:
[snip]

Yes, that's what I'm referring to…

> Your idea would be to make it more like:
> 
>  +        if 'user_id' in params:
>  +            # Project admins are able to modify per-user quotas.
>  +            authorize_action(context, 'update', require='projectadmin')
>  ...
>  +        else:
>  +            # Only admins are able to modify per-project quotas.
>  +            authorize_action(context, 'update', require='fulladmin')
> 
> Which is just as configurable in the policy, but won't result in an
> explosion of rules where we want to make similar distinctions. 

What I had in mind was a reorganization more like:

    authorization = authorize_action(context, 'update')
    if authorization == 'fulladmin':
        …
    elif authorization == 'projectadmin':
        …

Or something similar.

> It is
> confusing, though, since you'd need to document it in the policy with
> e.g

I have just been thinking about having a means of pre-declaring policies
with documentation strings, similar to what we currently do with
configuration settings; you wouldn't need to pre-declare, but it'd be
one way to provide documentation for policies.  (Frankly, I think we
need to document *all* of our current policy rules…)

> I'm leaning towards dropping this feature for now until we have a really
> compelling use case for it. Now that I understand the context a bit
> better, I think I'd be against adding this "global projectadmin role"
> idea at all.

To be clear, I never envisioned a "global projectadmin role" either; I
did think roles were already per-project.  I was merely using that as an
example of where this could be useful.

> The danger with leaving it in even if there's no good use case for it is
> that folks might find bad/confusing use cases for it :)

Heh.  Indeed, I suppose that is a danger.
-- 
Kevin L. Mitchell <kevin.mitchell at rackspace.com>