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..
2014-11-19 14:33 GMT+01:00 Sylvain Bauza <sba...@redhat.com>: > > Le 18/11/2014 20:05, Doug Hellmann a écrit : > > 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 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. >> > > 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. > > 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. > 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. > > 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. > > My 2 cts (too), > -Sylvain > > > Doug >> >> Just my $.02… >>> >>>  https://wiki.openstack.org/wiki/Boson >>> -- >>> Kevin L. Mitchell <kevin.mitch...@rackspace.com> >>> Rackspace >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStackfirstname.lastname@example.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStackemail@example.com >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStackfirstname.lastname@example.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev