Open Stack

On Wed, 2012-10-10 at 11:24 -0700, Vishvananda Ishaya wrote:
> I agree that this particular feature needs a compelling use case. Its too bad
> because the feature itself is cool I think it will just lead to bad decisions
> in the fulture.

Maybe someone else on this list has a compelling use case?  Anyone?

> To totally hijack the thread: I think the best thing we could do with policy
> is to start looking at it from an operator perspective. The plethora of options
> in the current policy.json is confusing at best.

No kidding; that was one of the factors in my mind when I set out to
create the policy interpreter.

> What we really need is some effort given to coming up with policy.json best
> practices:
> 
> a) making sure the policies are named in a consistent manner

I think we already largely have this, in nova at least.  That doesn't
mean that it's the *best* naming scheme, and my earlier suggestion of
pre-declaring policies with help text would probably also factor in
here.

> b) grouping the policies in a way that makes them easy to edit for operators.
> In other words, I think in most cases there are only a few policies that will be
> touched, so make configuring those easy

It had occurred to me to consider whether policies could be specified
via a ConfigParser-style file instead of a JSON file, which would allow
for easy policy grouping.  With the new policy specification format,
that style of configuration becomes quite possible.  However, we'd have
to carefully consider how to support older installations using the JSON
specification.

> c) standard definitions of which things should be policy controlled and ensuring
> that all of those are in place.
> d) documentation on configuring policies

Predeclaration of policy rules with help text could really help here,
but we probably also need a doc.  (Anne, does one already exist?)

> b) Centrally controlled policy (i.e. store it in keystone vs a bunch
> of separate files

That makes a lot of sense…perhaps a one-time download from keystone on
server start?  (It would be really good to try to at least cache results
of this from Keystone, so we don't introduce a bottleneck…)

> c) Delegation of rights (i.e. Giving another user a subset of rights. This is
> already being discussed in another thread.)

The obvious way of doing this, to my mind, would be to include some form
of special token in the request, stating to allow override of some
specific rule or set of rules.

> d) Programmable policy (we may get enough with rights delegation or user based
> quotas, but the basic use case we'd like to support is that a project owner could limit
> the actions of other project users. i.e. user a can launch new instances but user b
> cannot.)

That sounds good, but I worry that our policy code could become too
complex.  Still, maybe we'll figure out a way to do it that won't cause
too much complexity :)
-- 
Kevin L. Mitchell <kevin.mitchell at rackspace.com>