<div dir="ltr">All I can say at the moment is that Usage and Quota management is a crappy thing to do in OpenStack. Every service has it's own way of doing it both in clients and api's. +n+ for making a effort in standardizing this thing in a way that could be alike across projects..</div><div class="gmail_extra"><br><div class="gmail_quote">2014-11-19 14:33 GMT+01:00 Sylvain Bauza <span dir="ltr"><<a href="mailto:sbauza@redhat.com" target="_blank">sbauza@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Le 18/11/2014 20:05, Doug Hellmann a écrit :<div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Nov 17, 2014, at 7:18 PM, Kevin L. Mitchell <<a href="mailto:kevin.mitchell@rackspace.com" target="_blank">kevin.mitchell@rackspace.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, 2014-11-17 at 18:48 -0500, Doug Hellmann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I’ve spent a bit of time thinking about the resource ownership issue.<br>
The challenge there is we don’t currently have any libraries that<br>
define tables in the schema of an application. I think that’s a good<br>
pattern to maintain, since it avoids introducing a lot of tricky<br>
issues like how to manage migrations for the library, how to ensure<br>
they are run by the application, etc. The fact that this common quota<br>
thing needs to store some data in a schema that it controls says to me<br>
that it is really an app and not a library. Making the quota manager<br>
an app solves the API definition issue, too, since we can describe a<br>
generic way to configure quotas and other applications can then use<br>
that API to define specific rules using the quota manager’s API.<br>
<br>
I don’t know if we need a new application or if it would make sense<br>
to, as with policy, add quota management features to keystone. A<br>
single well-defined app has some appeal, but there’s also a certain<br>
amount of extra ramp-up time needed to go that route that we wouldn’t<br>
need if we added the features directly to keystone.<br>
</blockquote>
I'll also point out that it was largely because of the storage needs<br>
that I chose to propose Boson[1] as a separate app, rather than as a<br>
library.  Further, the dimensions over which quota-covered resources<br>
needed to be tracked seemed to me to be complicated enough that it would<br>
be better to define a new app and make it support that one domain well,<br>
which is why I didn't propose it as something to add to Keystone.<br>
Consider: nova has quotas that are applied by user, other quotas that<br>
are applied by tenant, and even some quotas on what could be considered<br>
sub-resources—a limit on the number of security group rules per security<br>
group, for instance.<br>
<br>
My current feeling is that, if we can figure out a way to make the quota<br>
problem into an acceptable library, that will work; it would probably<br>
have to maintain its own database separate from the client app and have<br>
features for automatically managing the schema, since we couldn't<br>
necessarily rely on the client app to invoke the proper juju there.  If,<br>
on the other hand, that ends up failing, then the best route is probably<br>
to begin by developing a separate app, like Boson, as a PoC; then, after<br>
we have some idea of just how difficult it is to actually solve the<br>
problem, we can evaluate whether it makes sense to actually fold it into<br>
a service like Keystone, or whether it should stand on its own.<br>
<br>
(Personally, I think Boson should be created and should stand on its<br>
own, but I also envision using it for purposes outside of OpenStack…)<br>
</blockquote>
Thanks for mentioning Boson again. I’m embarrassed that I completely forgot about the fact that you mentioned this at the summit.<br>
<br>
I’ll have to look at the proposal more closely before I comment in any detail, but I take it as a good sign that we’re coming back around to the idea of solving this with an app instead of a library.<br>
</blockquote>
<br></div></div>
I assume I'm really late in the thread so I can just sit and give +1 to this direction : IMHO, quotas need to managed thanks to a CRUD interface which implies to get an app, as it sounds unreasonable to extend each consumer app API.<br>
<br>
That said, back to Blazar, I just would like to emphasize that Blazar is not trying to address the quota enforcement level, but rather provide a centralized endpoint for managing reservations.<br>
Consequently, Blazar can also be considered as a consumer of this quota system, whatever it's in a library or on a separate REST API.<br>
<br>
Last thing, I don't think that a quota application necessarly means that quotas enforcement should be managed thanks to external calls to this app. I can rather see an external system able to set for each project a local view of what should be enforced locally. If operators don't want to deploy that quota management project, it's up to them to address the hetergenous setups for each project.<br>
<br>
My 2 cts (too),<br>
-Sylvain<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Doug<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Just my $.02…<br>
<br>
[1] <a href="https://wiki.openstack.org/wiki/Boson" target="_blank">https://wiki.openstack.org/<u></u>wiki/Boson</a><br>
-- <br>
Kevin L. Mitchell <<a href="mailto:kevin.mitchell@rackspace.com" target="_blank">kevin.mitchell@rackspace.com</a>><br>
Rackspace<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>