Open Stack

On Nov 17, 2014, at 7:18 PM, Kevin L. Mitchell <kevin.mitchell at 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.mitchell at rackspace.com>
> Rackspace
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev