On Feb 5, 2014, at 6:54 AM, Florent Flament <florent.flament-...@cloudwatt.com> 

> Vish:
> I agree that having roles associated with projects may complicate
> policy rules (although we may find ways to simplify the syntax?). It
> may be a sound choice to stick to a single scope for a given token.
> +1 for your quotas tree proposal. Maybe ensuring that the sum of
> subprojects quotas is lower (or equal) than the parent quota will be
> enough for most use cases.
> So far, I don't see any issue against your hierarchical projects
> proposal. IMHO, domains would not be much useful anymore.
> Vinod:
> I agree that you raised the same issue that I did. I needed some
> clarification.
> Regarding names (or IDs) that Nova uses, it would have to be "full
> project names" to avoid conflicts.

to be clear, I was not proposing at any point that we actually use
project names internally in the service databases, just that the names
are easier for humans to understand them for discussion. So when we


the database actually contains something like:


That said, the full hierarchical is necessary for quotas to ensure
that we don’t exceed any of the parent quotas for a project.

> Tiago, Vinod, Vish:
> I agree with Tiago that having policy files spread on every node
> doesn't look easy to maintain. I don't think that the service
> centralizing RBAC would have to know about the services "sets of
> operations". It could work by checking some tuple "(action, context)"
> against a set a rules, and answering whether the action is authorized
> or not.
> Moreover, if the same service were to centralize both RBAC and Quotas,
> then both could be checked in a row, for the provided tuple. The thing
> about Quotas, is that it requires the service to track resources
> usage, which can be done by the service providing RBAC, since each
> action would have to be authorized (and possibly tracked) by the RBAC
> engine.
> This is why I would argue in favor of a unique service providing RBAC
> and Quotas enforcement together.
> I don't know much about Gantt, so I guess that potential candidate for
> such service would be Keystone, Gantt, Ceilometer ? (which already
> agregates information about resources usage), a new service?.
> I have seen that some work had been started to centralize Quotas, but
> abandonned:
> * https://review.openstack.org/#/c/44878/
> * https://review.openstack.org/#/c/40568/
> There's also Identity API V3 providing (centralized?) policies
> management:
> * http://api.openstack.org/api-ref-identity.html#identity-v3
> I think it would be worth to try to clarify/simplify/rationalize the
> way RBAC/Quotas are working. Or am I missing something ?
> Although, I think this might be out of scope of the initial
> "Hierachical Multitenancy Discussion". Should it be moved to a new
> thread?

I vote for new thread. I’m not sure that policy and quota enforcement
can be done in a separate service for performance reasons. Even if we
can’t move enforcement into a central service like gantt or keystone, there
could still be a central location to store policy rules and quota values.


> Florent Flament
> <snip>

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

OpenStack-dev mailing list

Reply via email to