Open Stack

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…)

Just my $.02…

[1] https://wiki.openstack.org/wiki/Boson
-- 
Kevin L. Mitchell <kevin.mitchell at rackspace.com>
Rackspace