On Nov 17, 2014, at 7:18 PM, Kevin L. Mitchell <kevin.mitch...@rackspace.com> wrote:
> On Mon, 2014-11-17 at 18:48 -0500, Doug Hellmann wrote: >> I’ve spent a bit of time thinking about the resource ownership issue. >> The challenge there is we don’t currently have any libraries that >> define tables in the schema of an application. I think that’s a good >> pattern to maintain, since it avoids introducing a lot of tricky >> issues like how to manage migrations for the library, how to ensure >> they are run by the application, etc. The fact that this common quota >> thing needs to store some data in a schema that it controls says to me >> that it is really an app and not a library. Making the quota manager >> an app solves the API definition issue, too, since we can describe a >> generic way to configure quotas and other applications can then use >> that API to define specific rules using the quota manager’s API. >> >> I don’t know if we need a new application or if it would make sense >> to, as with policy, add quota management features to keystone. A >> single well-defined app has some appeal, but there’s also a certain >> amount of extra ramp-up time needed to go that route that we wouldn’t >> need if we added the features directly to keystone. > > I'll also point out that it was largely because of the storage needs > that I chose to propose Boson[1] as a separate app, rather than as a > library. Further, the dimensions over which quota-covered resources > needed to be tracked seemed to me to be complicated enough that it would > be better to define a new app and make it support that one domain well, > which is why I didn't propose it as something to add to Keystone. > Consider: nova has quotas that are applied by user, other quotas that > are applied by tenant, and even some quotas on what could be considered > sub-resources—a limit on the number of security group rules per security > group, for instance. > > My current feeling is that, if we can figure out a way to make the quota > problem into an acceptable library, that will work; it would probably > have to maintain its own database separate from the client app and have > features for automatically managing the schema, since we couldn't > necessarily rely on the client app to invoke the proper juju there. If, > on the other hand, that ends up failing, then the best route is probably > to begin by developing a separate app, like Boson, as a PoC; then, after > we have some idea of just how difficult it is to actually solve the > problem, we can evaluate whether it makes sense to actually fold it into > a service like Keystone, or whether it should stand on its own. > > (Personally, I think Boson should be created and should stand on its > own, but I also envision using it for purposes outside of OpenStack…) Thanks for mentioning Boson again. I’m embarrassed that I completely forgot about the fact that you mentioned this at the summit. 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. Doug > > Just my $.02… > > [1] https://wiki.openstack.org/wiki/Boson > -- > Kevin L. Mitchell <kevin.mitch...@rackspace.com> > Rackspace > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
