Salvatore, Joe, We do have this at the moment:
https://github.com/openstack/oslo-incubator/blob/master/openstack/common/quota.py -- dims On Wed, Oct 8, 2014 at 2:29 AM, Salvatore Orlando <sorla...@nicira.com> wrote: > > On 8 October 2014 04:13, Joe Gordon <joe.gord...@gmail.com> wrote: >> >> >> On Fri, Oct 3, 2014 at 10:47 AM, Morgan Fainberg >> <morgan.fainb...@gmail.com> wrote: >>> >>> Keeping the enforcement local (same way policy works today) helps limit >>> the fragility, big +1 there. >>> >>> I also agree with Vish, we need a uniform way to talk about quota >>> enforcement similar to how we have a uniform policy language / enforcement >>> model (yes I know it's not perfect, but it's far closer to uniform than >>> quota management is). >> >> >> It sounds like maybe we should have an oslo library for quotas? Somewhere >> where we can share the code,but keep the operations local to each service. > > > This is what I had in mind as well. A simple library for quota enforcement > which can be used regardless of where and how you do it, which might depend > on the application business logic, the WSGI framework in use, or other > factors. > >> >>> >>> >>> If there is still interest of placing quota in keystone, let's talk about >>> how that will work and what will be needed from Keystone . The previous >>> attempt didn't get much traction and stalled out early in implementation. If >>> we want to revisit this lets make sure we have the resources needed and >>> spec(s) in progress / info on etherpads (similar to how the multitenancy >>> stuff was handled at the last summit) as early as possible. >> >> >> Why not centralize quota management via the python-openstackclient, what >> is the benefit of getting keystone involved? > > > Providing this through the openstack client in my opinion has the > disadvantage that users which either use the REST API direct or write their > own clients won't leverage it. I don't think it's a reasonable assumption > that everybody will use python-openstackclient, is it? > > Said that, storing quotas in keystone poses a further challenge to the > scalability of the system, which we shall perhaps address by using > appropriate caching strategies and leveraging keystone notifications. Until > we get that, I think that the openstack client will be the best way of > getting a unified quota management experience. > > Salvatore > > >>> >>> Cheers, >>> Morgan >>> >>> Sent via mobile >>> >>> >>> On Friday, October 3, 2014, Salvatore Orlando <sorla...@nicira.com> >>> wrote: >>>> >>>> Thanks Vish, >>>> >>>> this seems a very reasonable first step as well - and since most >>>> projects would be enforcing quotas in the same way, the shared library >>>> would >>>> be the logical next step. >>>> After all this is quite the same thing we do with authZ. >>>> >>>> Duncan is expressing valid concerns which in my opinion can be addressed >>>> with an appropriate design - and a decent implementation. >>>> >>>> Salvatore >>>> >>>> On 3 October 2014 18:25, Vishvananda Ishaya <vishvana...@gmail.com> >>>> wrote: >>>>> >>>>> The proposal in the past was to keep quota enforcement local, but to >>>>> put the resource limits into keystone. This seems like an obvious first >>>>> step to me. Then a shared library for enforcing quotas with decent >>>>> performance should be next. The quota calls in nova are extremely >>>>> inefficient right now and it will only get worse when we try to add >>>>> hierarchical projects and quotas. >>>>> >>>>> Vish >>>>> >>>>> On Oct 3, 2014, at 7:53 AM, Duncan Thomas <duncan.tho...@gmail.com> >>>>> wrote: >>>>> >>>>> > Taking quota out of the service / adding remote calls for quota >>>>> > management is going to make things fragile - you've somehow got to >>>>> > deal with the cases where your quota manager is slow, goes away, >>>>> > hiccups, drops connections etc. You'll also need some way of >>>>> > reconciling actual usage against quota usage periodically, to detect >>>>> > problems. >>>>> > >>>>> > On 3 October 2014 15:03, Salvatore Orlando <sorla...@nicira.com> >>>>> > wrote: >>>>> >> Hi, >>>>> >> >>>>> >> Quota management is currently one of those things where every >>>>> >> openstack >>>>> >> project does its own thing. While quotas are obviously managed in a >>>>> >> similar >>>>> >> way for each project, there are subtle differences which ultimately >>>>> >> result >>>>> >> in lack of usability. >>>>> >> >>>>> >> I recall that in the past there have been several calls for unifying >>>>> >> quota >>>>> >> management. The blueprint [1] for instance, hints at the possibility >>>>> >> of >>>>> >> storing quotas in keystone. >>>>> >> On the other hand, the blazar project [2, 3] seems to aim at solving >>>>> >> this >>>>> >> problem for good enabling resource reservation and therefore >>>>> >> potentially >>>>> >> freeing openstack projects from managing and enforcing quotas. >>>>> >> >>>>> >> While Blazar is definetely a good thing to have, I'm not entirely >>>>> >> sure we >>>>> >> want to make it a "required" component for every deployment. Perhaps >>>>> >> single >>>>> >> projects should still be able to enforce quota. On the other hand, >>>>> >> at least >>>>> >> on paper, the idea of making Keystone "THE" endpoint for managing >>>>> >> quotas, >>>>> >> and then letting the various project enforce them, sounds promising >>>>> >> - is >>>>> >> there any reason for which this blueprint is stalled to the point >>>>> >> that it >>>>> >> seems forgotten now? >>>>> >> >>>>> >> I'm coming to the mailing list with these random questions about >>>>> >> quota >>>>> >> management, for two reasons: >>>>> >> 1) despite developing and using openstack on a daily basis I'm still >>>>> >> confused by quotas >>>>> >> 2) I've found a race condition in neutron quotas and the fix is not >>>>> >> trivial. >>>>> >> So, rather than start coding right away, it might probably make more >>>>> >> sense >>>>> >> to ask the community if there is already a known better approach to >>>>> >> quota >>>>> >> management - and obviously enforcement. >>>>> >> >>>>> >> Thanks in advance, >>>>> >> Salvatore >>>>> >> >>>>> >> [1] https://blueprints.launchpad.net/keystone/+spec/service-metadata >>>>> >> [2] https://wiki.openstack.org/wiki/Blazar >>>>> >> [3] https://review.openstack.org/#/q/project:stackforge/blazar,n,z >>>>> >> >>>>> >> _______________________________________________ >>>>> >> OpenStack-dev mailing list >>>>> >> OpenStack-dev@lists.openstack.org >>>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >> >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > Duncan Thomas >>>>> > >>>>> > _______________________________________________ >>>>> > 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 > -- Davanum Srinivas :: https://twitter.com/dims _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev