<div dir="ltr"><div>Hello, </div><div><br></div><div>Currently, there is a blueprint for creating a Domain in New Quota Driver who is waiting approval, but that is already implemented. I believe that is worth checking out.</div>
<div><br></div><div><div><a href="https://blueprints.launchpad.net/nova/+spec/domain-quota-driver">https://blueprints.launchpad.net/nova/+spec/domain-quota-driver</a><br></div></div><div><br></div><div><div>Any questions I am available. </div>
<div><br></div><div>Regards, </div><div><br></div><div>Raildo Mascena</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-02-06 7:22 GMT-03:00 Florent Flament <span dir="ltr"><<a href="mailto:florent.flament-ext@cloudwatt.com" target="_blank">florent.flament-ext@cloudwatt.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Spliting from thread "[openstack-dev][keystone][nova] Re: Hierarchicical Multitenancy Discussion"<br>
<br>
Vinod, Vish:<br>
<br>
I understand that actions are different from one service to the<br>
other. What I meant is that the RBAC enforcement engine, doesn't need<br>
to understand the "meaning" of an action. It can allow (or not) an<br>
access, based on the action (a string - without understanding it), a<br>
context (e.g. a dictionary, with data about the user, role, ...)  and<br>
a set of rules.<br>
<br>
>From the performance point of view, I agree that there may be an<br>
issue. Centralizing RBAC enforcement would mean that every API call<br>
has to be checked against a centralized controler, which could<br>
generate a heavy load on it, especially for services that require a<br>
heavy use of the APIs (like Swift for object storage). I believe that<br>
the issue would be the same for quotas enforcement. Now that I'm<br>
thinking about that, there's actually a similar issue with UUID tokens<br>
that have to be checked against Keystone for each API call. And the<br>
solution chosen to avoid Keystone to become a single point of failure<br>
(SPOF) has been to implement the PKI tokens. They allow Openstack<br>
services to work without checking Keystone every call.<br>
<br>
I agree with Vish, that a good compromise may be to have RBAC/quotas<br>
enforcement done in each specific service (altough by using a common<br>
middleware, like for tokens validation?). At the same time, RBAC rules<br>
and Quotas limits may be stored in a central place. There's already<br>
some discussion that have been made (at least on the Quotas) some<br>
months ago:<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2013-December/020799.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-December/020799.html</a><br>
<br>
I've got to catchup with what's been done on RBAC and Quotas, and see<br>
if I can propose some improvements. If you have some interesting links<br>
about blueprints / reviews about that I'd be interested.<br>
<br>
+1 for the implementation of domain Quotas for Nova.<br>
<br>
Florent Flament<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Raildo Mascena<br>Bacharel em Ciência da Computação - UFCG<br><div>Desenvolvedor no Laboratório de Sistemas Distribuidos - UFCG<br></div></div>
</div>