On Nov 19, 2014, at 9:51 AM, Sylvain Bauza <sba...@redhat.com> wrote:
> > Le 19/11/2014 15:06, Doug Hellmann a écrit : >> On Nov 19, 2014, at 8:33 AM, Sylvain Bauza <sba...@redhat.com> wrote: >> >>> 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[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. >>> 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. >> I’m not sure what this means. You want the new service to be optional? How >> would apps written against the service find and manage quota data if the >> service isn’t there? > > My bad. Let me rephrase it. I'm seeing this service as providing added value > for managing quotas by ensuring consistency across all projects. But as I > said, I'm also thinking that the quota enforcement has still to be done at > the customer project level. Oh, yes, that is true. I envision the API for the new service having a call that means “try to consume X units of a given quota” and that it would return information about whether that can be done. The apps would have to define what quotas they care about, and make the appropriate calls. > > So, I can imagine a client (or a Facade if you prefer) providing quota > resources to the customer app which could be either fetched (thru some > caching) from the service, or directly taken from the existing quota DB. I’m not sure we want both solutions. We need to consider a migration path, but for simplicity’s sake if we’re going to create a new quota service we should just use that and not also have a separate built-in implementation. > > In order to do that, I could imagine those steps : > #1 : customer app makes use of oslo.quota for managing its own quota resources > #2 : the external app provides a client able to either query the app or make > use of oslo.quota for looking inside > #43 : the customer app changes its current usage of oslo.quota to the > external app client > > > Let me know if you need futher details. > -Sylvain > >> Doug >> >>> My 2 cts (too), >>> -Sylvain >>> >>>> 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 >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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
