<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 18 November 2014 01:18, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, 2014-11-17 at 18:48 -0500, Doug Hellmann wrote:<br>
> 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></span></blockquote><div><br></div><div>My point of view is that it might be acceptable for a library to have its own database, to an extent where the data the library manages belong to the library itself.</div><div>If that is possible then the library can come with its own, small, database, and its evolution could be managed with a migration timeline specific to the library.</div><div><br></div><div>However, in this case the data the library handles - resource usage info - actually belong to the consumer application. The quota library might expose methods for managing resource usage in an abstract way, but this probably sounds more complex than what it should be.</div><div>Furthermore, a solution where the library "augments" the consumer application schema sounds the "really wrong" bell to me, unless you can convince me otherwise.</div><div>Therefore the app route at this stage looks more favorable, as Doug suggests. I tried to devise a library which operates on an abstract data model, which is then supplied by the consumer application, but that then probably just shifts the problem a little, since the next issue to face is ensuring the consumer application uses a data model which can be understood by the library.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
><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></span></blockquote><div><br></div><div>I think having a centralised API endpoint for quota management makes sense.</div><div>I am still not entirely sure it will make sense for quota enforcement (just like I'm not yet sure it makes sense for authorization)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
</span>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></blockquote><div><br></div><div>It is true that the structure of quota-tracked resource can become easily fairly complex.</div><div>However I think that this alone, does not prove the need of implementing it as a new service.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div><br></div><div>I reckon this plan makes sense. I will also look into the Boson proposal, and report back to this thread.</div><div>The aspect that does not convince me yet is the apparent need for an additional round trip for requests, in addition to the one we do to Keystone for authN.</div><div>Also it's actually 2 round trips, If you consider that you'll need one for booking quota, and another for committing/cancelling a reservation.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(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><div><br></div><div>I recall several people, including me, used to claim neutron (then quantum) could be used for purposes outside of openstack.</div><div>Fast-forward 3 years, and neutron can barely work with OpenStack only...</div><div><br></div><div>Summarising, it makes sense for the time being to freeze the oslo-spec proposal for a quota library.</div><div>I guess in the meanwhile I'll use my own github account to build something which might or might not turn into an oslo library...</div><div><br></div><div>Salvatore</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Just my $.02…<br>
<br>
[1] <a href="https://wiki.openstack.org/wiki/Boson" target="_blank">https://wiki.openstack.org/wiki/Boson</a><br>
<span class="HOEnZb"><font color="#888888">--<br>
Kevin L. Mitchell <<a href="mailto:kevin.mitchell@rackspace.com">kevin.mitchell@rackspace.com</a>><br>
Rackspace<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div></div>