<div dir="ltr">Apparently, like everything Openstack-y we have a gathered a good crowd of people with different opinions, more or less different, more or less strong.<div>My only strong opinion is that any ocean-boiling attempt should be carefully avoided, and any proposed approach should add as little as possible in terms of delays and complexity to the current process.<br></div><div>Anyway, I am glad nobody said so far "QaaS". If you're thinking to do so, please don't. Please.</div><div><br></div><div>The reason for the now almost-abandoned proposal for a library was to have a simple solution for allowing every project to enforce quotas in the same ways.</div><div>As Kevin said, managing quotas for resources and their sequence attributes (like the sec group rules for instance), can become pretty messy soon. As of today this problem is avoided since quota management logic is baked in every project's business logic. The library proposal also shamefully avoided this problem - by focusing on enforcement only.</div><div><br></div><div>For enforcement, as Doug said, this is about answering the question "can I <font face="arial, sans-serif">consume X units of a given resource?". In a distributed, non-locking, world, this is not really obvious. A Boson-like proposal would solve this problem by providing a centralised enforcement point. In this case the only possible approach is one in which such centralised endpoint does both enforcement and management.</font></div><div><font face="arial, sans-serif">While I too think that we need a centralised quota management endpoint, be it folded in Keystone or not, I still need to be convinced that this is the right architectural decision for enforcing quotas.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">First, "can I consume X unit of a given resource" implies the external service should be aware of current resource usage. Arguably it's the consumer service (eg: nova, cinder) that owns this information, not the quota service. The quota service can however be made aware of this in several ways:</font></div><div><font face="arial, sans-serif">- notifications. In this case the service will also become a consumer of a telemetry service like ceilometer or stacktach. I'm not sure we want to add that dependency</font></div><div><font face="arial, sans-serif">- the API call itself might ask for reserving a given amount resource and communicate at the same time resource usage. This sounds better, but why would it be better than the dual approach, in which the consumer service makes the reservation using quota values fetched by an external service. Between quota and usage, the latter seem to be the more dynamic ones; quotas can also be easily cached.</font></div><div><font face="arial, sans-serif">- usage info might be updated when reservations are committed. This looks smart, but requirers more thinking for dealing with failure scenarios where the failure occurs once resources are reserved but before they're committed and there is no way to know which ones were actually and which ones not.</font></div><div><br></div><div>Second, calling an external service is not cheap. Especially since those calls might be done several times for completing a single API request. Think about POST /servers with all the ramifications into glance, neutron, and cinder. In the simplest case we'd need two calls - one to reserve a resource (or a set of resources), and one to either confirm or cancel the reservation. This alone adds two round trips for each API call. Could this scale well? To some extent it reminds me of the mayhem that was the nova/neutron library before caching for keystone tokens was fixed.</div><div><br></div><div><font face="arial, sans-serif">Somebody mentioned an analogy with AuthZ. For some reason, perhaps different from the reasons of who originally brought the analogy, I also believe that this is a decent model to follow.</font></div><div><font face="arial, sans-serif">Quotas for each resource, together with the resource structure, might be stored by a centralised service. This is pretty much inline with Boson's goals, if I understand correctly. It will expose tenant-facing REST APIs for quota management and will finally solve the problem of having a standardized way for handling quotas, regardless of whether it stand as its own service or is folded into Keystone, operators should be happier. And there's nothing more satisfying that the face of a happy operator... provided we also do not break backward compatibility!</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Enforcement is something that in my opinion should happen locally, just like we do authZ locally using information provided by Keystone upon authentication. The issue Doug correctly pointed out however is that quota enforcement is a too complex to be implemented in a library, like, for instance, oslo.policy.</font></div><div><font face="arial, sans-serif">So, assuming there might consensus on doing quota enforcement locally in the consumer application, what should be the 'thing' that enforces policy if it can't be a library? Could it be a quota agent which communicates with quota server, caches quota info? If yes, APIs like those for managing reservation, over which transport should be invoked? IPC, AMQP, REST? I need to go back to the drawing board to see if this can possibly work, but in the meanwhile your feedback is more than welcome.</font></div><div><font face="arial, sans-serif"><br></font></div><div>Salvatore</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 20 November 2014 00:39, Kevin L. Mitchell <span dir="ltr"><<a href="mailto:kevin.mitchell@rackspace.com" target="_blank">kevin.mitchell@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On Thu, 2014-11-20 at 10:16 +1100, Blair Bethwaite wrote:<br>
> For actions initiated directly through core OpenStack service APIs<br>
> (Nova, Cinder, Neutron, etc - anything using Keystone policy),<br>
> shouldn't quota-enforcement be handled by Keystone? To me this is just<br>
> a subset of authz, and OpenStack already has a well established<br>
> service for such decisions.<br>
<br>
</span>If you look a little earlier in the thread, you will find a post from me<br>
where I point out just how complicated quota management actually is.  I<br>
suggest that it should be developed as a proof-of-concept as a separate<br>
service; from there, we can see whether it makes sense to roll it into<br>
Keystone or maintain it as a separate thing.<br>
<span>--<br>
Kevin L. Mitchell <<a href="mailto:kevin.mitchell@rackspace.com" target="_blank">kevin.mitchell@rackspace.com</a>><br>
Rackspace<br>
<br>
<br>
</span><div><div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</div></div></blockquote></div><br></div></div></div></div>